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About This Guide 


Purpose 


This manual is one in a series designed to instruct and guide the programmer in the 
use of the Unisys Operating System/3 (OS/3). 


Scope 


This guide describes the OS/3 system service programs (SSP) and their effective use. 
The system service programs include the system librarians, the linkage editor, and the 
standard system utilities. 


Audience 


This guide is intended for the novice programmer with a basic knowledge of data 
processing, but with limited programming experience, and for the more sophisticated 
programmer whose experience is limited to systems other than Unisys systems. 


Organization 
This guide is divided into the following parts, each containing one or more sections: 
Part 1. OS/3 System Service Programs Repertoire 
Introduces you to the various system service programs through descriptions of their 
intended purposes within the OS/3 operating system, their capabilities, and the terms 
peculiar to their functional operation. 
Part 2. The Librarians 
Describes the functional characteristics of the system librarians relevant to you, the 
control statements you may use to direct their operation, and the various library 
mapping elements they are capable of producing. 


Part 3. The Linkage Editor 


Describes the functional characteristics, programming considerations, and control 
statements required to allow you to effectively use the linkage editor as it is intended 
to be used. Also describes the link-edit mapping data produced by the linkage editor 
for every load module it produces. 
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Part 4. System Utilities 


Describes the utility programs provided by OS/3 to initialize disk, diskette, and tape 
volumes; copy disk, diskette, and tape volumes; patch system programs; print 
software maintenance correction listings; maintain the operating system; and perform 
buffer analysis. 


Part 5. Appendixes 


Appendix A presents canned job control streams and the document numbers where 
they are described. 


Appendix B describes the code set components that, when combined in a particular 
sequence, make up a program source module, a macro/jproc source module, an object 
module, a load module, or a group code set module. 


Appendix C describes the SAT library structures. 


Appendix D describes the file transfer utility (PCTRAN) that permits the transfer of 
files between a Unisys personal computer (PC) and the Unisys System 80. 


Related Product Information 


vi 


To fully understand and appreciate the functions performed by the system service & 
programs, you should be familiar with the information contained in current versions of 
the following Unisys publications. The degree of familiarity required varies with the 
product in question. For example, the linkage editor user has to be familiar with 
almost all of the documents. On the other hand, those using the librarian and system 
utilities need only a few of them. 

System Service Programs Programming Reference Manual (UP-8842) 

Job Control Language Programming Guide (UP-9986) 

System Messages Reference Manual (UP-8076) 

1974 American Standard COBOL Programming Reference Manual (UP-8613) 
Consolidated Data Management Programming Guide (UP-9978) 


Consolidated Data Management Macroinstructions Programming Guide 
(UP-9979) 


Supervisor Macroinstructions Programming Reference Manual (UP-8832) 


Integrated Communications Access Method (ICAM) Programming Reference 
Manual (UP-9749) 
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é Installation Guide (UP-8839) 
Interactive Services Operating Guide (UP-9972) 


Menu Services Technical Overview (UP-9317) 
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Section 1 
Introduction 


1.1. General Information 


The system service programs (SSP) are those programs required to support the 
operation and organization of the operating system in which your problem programs 
are to be executed. These programs allow you to construct and reorganize the program 
hbraries in your system, create program modules for execution in your system, 
initialize tape and disk volumes for the storage of your program and data files, and 


obtain printouts of main storage. 


The system service programs are introduced and outlined briefly in this section and 
discussed in full detail in the subsequent parts of this document. The common names 
and program names of the system service programs and where they are described are: 


Common 
Name 


System librarian for system access technique 


(SAT) files 


System librarian for multiple .ndexed random 


access method (MIRAM) files 
Linkage editor 

Initializing disk volumes 

Assign alternate track 

Tape prep 

Disk dump/restore 

List software maintenance corrections 
Diskette copy 

8416/8418 disk copy 

8419 disk copy 


8430/8433 disk copy 
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Program 
Name 


LIBS 
MLIB 


LNKEDT 
DSKPRP 
DSKPRP 
TPREP 
DMPRST 
SMCLIST 
SU$CPY 
SU$C16 
SU$C19 


SU$CSL 


Section 


2 and 3 


2 and 3 


4 thru 8 
9 

10 

11 

12 

13 

14 

15 

15 


15 
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Common Program 

Name Name Section 
System utility symbiont SU 16 
Create file definition program CFDP 17 
Hardware utilities (interactive HU 12 and 15 
DMPRST and SU$C19) 


1.2. System Librarians 


There are two system librarians that can maintain and manipulate both your system 
and user libraries within OS/3. For all non-MIRAM library files, you use the SAT 
librarian (LIBS). For MIRAM libraries, you use the MIRAM librarian (MLIB). 


The librarians are also used during OS/3 system generation to tailor the SYSRES’ 
program libraries. The librarians are capable of manipulating the library files at the 
user’s request and in the specific manner directed. The functions performed by the 
librarians are controlled by a set of integrated subroutines, file tables, and overlay 
segments associated with the supported individual functions. 


Your OS/3 system can support several independent system and user program 
libraries, and the librarians can be used to maintain each one. A program library 
consists of one or more library files. A single library may contain both user and system 
files, or it may be used exclusively for one or the other. Each file within the program 
library contains a directory partition, the library file directory, and two data 
partitions. 


The program library files can be composed of any combination of the following: 

¢ Program source modules (language processor code) 

© Macro/jproc source modules (language processor code/job control) 

¢ Object modules (language processor output/linkage editor input) 

© Load modules (linkage editor output) 

¢ Module groups 

The library files may be composed of system or user code used for either program 
generation or execution. The code may be in any of the listed formats and may, from 
time to time, change in form, content, or relative position within a given file. The 
mixing and grouping of module types is a user option, and module groups can contain 


modules of the same or different types. Figure 1-1 depicts the structure of a SAT 
program library, showing various component configurations. 
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The librarians can perform, on all or specific portions of library files, such tasks as 
copying, merging, listing, or punching on cards the contents of specified files. The 
librarians can also add or delete from a file or files. In fact, the OS/3 librarians can 
perform all the tasks you may be expected to require for program file management. 
These tasks are initialized and directed through a set of control statements introduced 
to the librarians through the control stream. The librarians and the function 
associated with each task are fully explained in Part 2 of this guide. 


DISK 


vtoc Sea tia 
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FORMAT 
LABELS 





(SYSTEM OR USER) 







PROGRAM 
LIBRARY 
(SYSTEM OR USER) 

















LIBRARY 
FILE2 
(SYSTEM OR USER) 


LIBRARY 
FILEn 
(SYSTEM OR USER) 


LIBRARY 
FILE1 
















PROGRAM 
SOURCE(S) 
MODULES 


SOURCE 
STATEMENTS 
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ASSEMBLER 
COBOL 
RPG 
FORTRAN 
CONTROL 
STATEMENTS 
SOURCE 
DATA 
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MACRO/JPROC 
SOURCE 
MODULES (M) 


SOURCE 
STATEMENTS 





MODULE 
GROUP 







OBJECT(O) 
MODULES 


LOAD(L) 
MODULES 






SOURCE 
MODULES 





ASSEMBLER HEADER 
JOB CONTROL TEXT 
TRANSFER 


OBJECT 
MODULES 





TRANSFER 





Figure 1-1. SAT Program Library Structure 
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1.3. Linkage Editor 
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The OS/3 linkage editor (LNKEDT) converts and combines object modules and object 
module elements (control sections and common sections) produced by the OS/3 
language processors into modules that can be loaded into a system by the supervisor 
for execution. The modules produced by the linkage editor are called load modules. 
Only programs in load module form can be executed in an OS/3 environment, and the 
only way to convert object modules into a load module is by using the linkage editor. 


The linkage editor produces three types of load modules: 
¢ Single-phase (reentrant or nonreentrant) 

¢ Multiphase (nonreentrant) 

¢ Multiregion (nonreentrant) 


A single-phase load module consists of a single program segment loaded into main 

storage each time the program is to be executed. Unless otherwise directed, the 

linkage editor will always produce a single-phase load module. Multiphase and 

multiregion load modules are composed of more than one program segment, each 

segment being a program phase loaded into main storage and executed individually, 

as required by the logic of the program. The linkage editor will create a multiphase or 

multiregion load module from one or more object modules only if directed to do so by 

the user through the linkage editor control statements. Savings in main storage space @ 
and increased system performance can be realized through proper application of 

multiphasing and multiregioning. 


The capabilities of the linkage editor provide the system user with the following 
advantages: 


e Ifa program logic error is discovered in a particular object module or control 
section of a program, only the incorrect element needs to be recompiled or 
reassembled. Afterward, the entire program can be relinked without extensive 
reassembling or recompiling. 


¢ Subroutines or elements required in more than one program phase need to be 
‘preserved only once as relocatable object code because a single module can be 
individually included in any number of load modules by the linkage editor. 

¢  Asingle load module may actually consist of object elements produced by several 
different language processors because all processors generate compatible output 
object code acceptable to the linkage editor. 


¢ Reentrant modules can be shared by other load modules, resulting in the overall 
reduction of main storage requirements. 


The capabilities of the linkage editor are described in detail in Part 3. © 
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@ 1.4. system utilities 


The system utilities are available to do the following: 


Test and prepare all tape, diskette, and disk volumes for use by OS/3. 


Apply patch corrections to certain areas of OS/3 normally inaccessible to the user. 


1.4.1. Disk Utilities 


The disk utilities perform the following functions: 


Initialize 8417, 8470, and 8494 nonremovable disks; 8417 fixed-head 
nonremovable disk; and 8416, 8417, 8418, 8419, 8430, and 8433 removable disks 


Perform surface analysis on disk volumes 

Assign alternate tracks on disk volumes 

Dump, restore, or copy disk, tape, or diskette volumes 
Dump or restore disk, tape, or diskette files 

Copy disk files 

Place initial microprogram load (IMPL) modules on disk 


Assign new volume serial numbers to disks 


1.4.2. Diskette Utilities 


The diskette utilities perform the following functions: 
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Initialize diskettes 

Perform surface analysis on diskette volumes 

Place IMPL modules on diskette volumes 

Tndieate whether diskette is to be used as an initial program load (IPL) volume 


Format diskettes in data set label mode (DSL) or format label mode (FLB) 
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1.4.3. Tape Utilities 


The tape utilities initialize tape volumes for use in the system. Up to 36 tapes can be 
initialized at one time. 


1.4.4. Hardware Utilities (HU) 


The hardware utilities consist of the dump/restore and the disk copy routines executed 
interactively. 


1.5. List Software Maintenance Corrections (SMCLIST) 


You can use the SMCLIST canned job control stream to print a listing of all the 
software maintenance corrections (SMCs) contained in the SMCLOG file. 


1.6. System Utility Copy Routines 


System utility copy routines perform the following functions: 
¢ Copy and verify System 80 diskettes (SU$CPY) 


¢ Copy and verify these disks: 8416/8418 (SU$C16), 8419 (SU$C19), and 8430/8433 
(SU$CSL). 


1.7. System Utility Symbiont (SU) 


The system utility symbiont is a multipurpose utility enabling the operator to perform 
different utility operations from the system console. For example, printing a diskette 
and printing a tape. 


1.8. Program Error Checking (UPSI Byte) 


The OS/3 system provides every job with a 12-byte communications region residing in 
the job preamble. The last byte of this region is the user program switch indicator 
(UPSD. The UPSI byte is used to pass information from one job step to the next job 
step and to indicate the presence of program errors. The librarian, the linkage editor, 
the utilities, the dump routines, and other executable system components set the 
UPSI byte if errors are detected. You can test the UPSI byte during program 
execution to determine the nature and severity of any errors. 
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The basic bit usage of the UPSI byte is 
e §=6BitO 


A1 in the first bit (X‘80’) indicates a catastrophic error. Subsequent job steps 
probably will not function and the job will terminate. 


e =6Bitl 


A 1 in this bit (X‘40’) indicates a serious error. A serious error could affect 
subsequent job steps or result in incomplete or erroneous processing results. 


° Bit2 


A1 in this bit (X'20’) indicates a statement format or syntax error. The affected 
statement will not function, and this may or may not have an effect on 
subsequent job steps. 


The UPSI byte can be useful in contingency error processing. For example, the byte 
can be examined and, if certain conditions prevail, can cause a branch to error 
handling routines. The SKIP job control statement is used to perform the test. The 
following examples show how you can use the SKIP job control statement. 





Example 1 
1 10 16 
1. // JOB DSKPRP 
2. // OVC 20 // LFD PRNTR 
3. // OVC 51 // VOL DSP@28 // LFD DISKIN 
4. // EXEC DSKPRP 
5. /$ 
6. SERNR=DSP028, PARTL=V 
7. /* 
8. // SKIP ENDS, 1 
9. . Additional 
16. job steps 
11. 7 as required 
12. | //ENDS NOP 
13. | /& 
14. | // FIN 


In Example 1, you check the UPSI byte to see if a fatal error (X‘80’) has occurred. If 
the leftmost bit (bit 0) of the UPSI byte contains a binary 1 (line 8), then all the other 
job steps are bypassed and control is transferred to the NOP job control statement 
with the label ENDS (line 12). The NOP job control statement provides you with an 
address for the SKIP with no function being performed. The /& job control statement 
terminates our job while the //FIN terminates the card reader operation. 
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Example 2 





// JOB DSKPRP 

// DVC 28 // LFD PRNTR 

// OVC 51 // VOL DSP@28 // LFD DISKIN 
// EXEC OSKPRP 

/$ 


SERNR=DSP@28, PARTL=V 
/* 
// SKIP WARN,@1 
// SKIP FATAL, 1 
10. | // SKIP EXIT 
11. | //WARN OPR 'WARNING-A NON-FATAL ERROR HAS OCCURRED! 
12. | // SKIP EXIT 
13. | //FATAL OPR ‘FATAL ERROR-JOB TERMINATED-CORRECT AND RERUN! 
14. | // SKIP ENDOF JOB 
15. | //EXIT NOP 


Tt Se SANS 


16. : Additional 
17. P job steps 
18. < as required 
19. //ENDOF JOB NOP 

20. | /& 

21. | // FIN 


In Example 2, you check for both the fatal (X‘80’) and warning errors (X‘40’) and the 
display of appropriate messages on the system console. If a warning error has 
occurred, bit 1 of the UPSI byte is a binary 1 (line 8), then you skip to the label WARN 
on the OPR job control statement and print the warning message (line 11). After 
processing the OPR statement, the SKIP job control statement (line 12) is the next job 
control statement processed. Here, you skip down to the label EXIT on the NOP job 
control statement (line 15). As mentioned earlier, the NOP acts as an ending point for 
the SKIP control statement. The remaining job steps follow the NOP statement and 
are processed accordingly. Following the last job step, the NOP statement on line 19 is 
processed with no action being performed. Your job then terminates normally through 
the /& and //FIN job control statements. 


If a fatal error occurs, bit 0 of the UPSI byte is a binary 1 (line 9) and you skip down to 
the label FATAL on the OPR statement (line 13) and print the specified message. The 
SKIP job control statement (line 14) skips down to the label END OF JOB on the NOP 
statement, thus bypassing your remaining job steps, and terminates your job. 


If no errors occurred, neither SKIP (lines 8 and 9) will be taken, and the SKIP job 
control statement (line 10) skips over the OPR statements to the remaining job steps. 
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The UPSI byte setting and the error count appear on the printout or map listing for 
the particular job. The UPSI byte value can also be retrieved by issuing the GETCOM 
supervisor macroinstruction in your BAL program. For more information on the 
GETCOM macro, refer to the Supervisor Macroinstructions Programming Reference 
Manual (UP-8832). For more information on the SKIP job control statement, refer to 
the Job Control Language Programming Guide (UP-9986). 


1.9. Using Workstations 


OS/3 enables you to run system service programs interactively. This means two 
things: 


1. You can build a control stream to execute the system service programs at a 
workstation, as opposed to punching it on cards or writing it to a diskette. 


2. You can initiate the running of the control stream from the workstation, as 
opposed to asking the system operator to run your job for you. 


The easiest way to build a control stream from a workstation is by using the job 
control dialog. The job control dialog is an interactive facility of OS/3 that allows you 
to describe your job’s requirements to it in English, in response to a series of 
questions, and then produces as its output the job control stream needed by OS/3 to 
run your job. The control stream produced by the job control dialog is virtually 

@ identical to the control stream that you would have to produce if you were running 
your job in a batch environment. Only now, you do not have to be concerned with the 
intricacies of the job control language. The job control dialog eliminates this 
requirement on your part. 


After you have answered all the questions presented to you by the job control dialog, 
the job control dialog builds a control stream and stores it in a permanent library file 
for you. From here, you can initiate its running by simply keying in the appropriate 
system RUN command, 0r, if you'd rather, you can change the contents of the control 
stream using another interactive facility of OS/3 called the general editor. 


The procedures for activating the job control dialog, initializing the running of a job, 
and activating the general editor are described in detail in the Interactive Services 
Operating Guide (UP-9972). 

More detailed descriptions of the job contro! dialog and the file editor are presented in 


the Job Control Language Programming Guide (UP-9986), and the General Editor 
(EDT) Operating Guide (UP-9976). 
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1.10. Statement Conventions 


The conventions used to illustrate the control statements and system console message 
displays presented in this manual are: 


¢ Positional parameters must be written in the order specified in the operand field 
and must be separated by commas. When a positional parameter is omitted, the 
comma must be retained to indicate the omission, except for the case of omitted 
trailing parameters. 


Examples 


Assume that INCLUDE is a linkage editor control statement with three 
optional positional parameters: A, B, and C. 


INCLUDE A 
INCLUDE A,B 
INCLUDE A,B,C 
INCLUDE A, ,C 


e Akeyword parameter consists of a word or a code immediately followed by an 
equals sign, which is, in turn, followed by a specification. Keyword parameters 
can be written in any order in the operand field. Commas are required only to 
separate parameters. 





Examples 


Assume that LINKOP is a linkage editor control statement with three 
optional keyword parameters: ALIB, RLIB, and OUT. 


LINKOP ALIB=OBJFIL,RLIB=$Y$OBJ , OUT=$Y$LOD 
LINKOP ALIB=OBJFIL,RLIB=$Y$OBJ 

LINKOP RLIB=$YSOBJ,ALIB=OBJFIL 

LINKOP OUT=$Y$LOD 


¢  Apositional or keyword parameter may contain a sublist of parameters, called 
subparameters, separated by commas and enclosed in parentheses. The 
parentheses must be coded as part of the list. The subparameters within the 
parentheses may be positional, in which case the comma must be retained if a 
parameter is omitted, except for the case of trailing parameters, or they may be 
nonpositional. The description of the subparameters indicates whether they are 
positional or nonpositional. 


Examples 


FIELDS=({CADDRI[ ,A2TDIL , FREQ)) 
” REDO=(MERGE, Label ,reel, to) 
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Uppercase letters, commas, equals signs, apostrophes, and parentheses must be 
coded and displayed exactly as shown. The exceptions are acronyms, which are 
part of generic terms representing information to be supplied by the programmer. 


Examples 
CMcc NUMBCHAR=n 


X'aa’ (NOV) 
ALIB= 


Lowercase letters and words are generic terms representing information that 
must be supplied by the user. Such lowercase terms may contain hyphens and 
acronyms (for readability). 


Examples 


lfn 

name 
group-name 
comments 
s1,...,8n 


Information contained within braces represents mandatory entries of which one 
must be chosen. 


Examples 
filename 
(N) 
SYSRUN 

Information contained within brackets represents optional entries that 

(depending upon program requirements) are included or omitted. Braces within 

brackets signify that one of the specified entries must be chosen if that parameter 

is to be included. 

Examples 


[sequence-no] 
CALIB=filename] 


{Sut 
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An optional parameter with a list of optional entries may have a default @ 
specification that is supplied by the operating system when the parameter is not 

specified by the user. Although the default may be specified by the user with no 

adverse effect, it is considered inefficient to do so. For easy reference, when a 

default specification occurs in the format delineation, it is printed on a shaded 

background. If, by parameter omission, the operating system performs some 

complex processing other than parameter insertion, it is explained under an “If 

omitted” statement in the parameter description. 


Examples 
» {input-lfn 


An ellipsis (...) indicates the presence of a variable number of entries. 





Example 


param-1,...,param-n 





Commas are required when positional parameters are omitted, except after the 
last parameter specified. 


Example 


positional -parameter-1,positional -parameter -2, ,positional -parameter -4 


Note: There are three standard character sets used with Unisys printers: two are 
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48-character print sets, and the third is a 63-character print set. Thus, not all 
characters are printable on all machines, and print code conversions are 
necessary to represent nonprintable characters when a 48-character print set is 
being used. The programming examples presented in this guide were produced 
using the standard 48-character business print set and, therefore, make use of 
some of these conversion print characters. For example, an equals sign (=) is 
represented by a percent symbol (%), a left parenthesis by a number symbol (#), 
and a right parenthesis by an at symbol (@). 
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Overview of the Librarians 


Introduction 


The Unisys Operating System/3 (OS/3) provides two librarian utility programs to 
maintain the SAT and MIRAM libraries. The SAT librarian utility called LIBS is used 
to maintain SAT files in system and user program libraries. The MIRAM librarian 
utility called MLIB is used to maintain screen format modules, help screen modules, 
saved run library modules, and menu modules in MIRAM files. 


Although LIBS and MLIB are primarily disk utilities, they can be used to maintain 
files on tape, diskette, or panned cards. They can also transfer files from one storage 
medium to another. 


Library maintenance is performed by running a job that executes the appropriate 
librarian utility program. The input that the user must supply with this program is a 
series of librarian control statements. Each statement specifies a particular librarian 
operation, such as a module copy or deletion. So the statements used in each librarian 
job vary, depending on the kind of maintenance needed. When the job is run, the 
statements are executed in the order that they are supplied in the job. As output, the 
librarian produces updated files, punched cards, listings, or a combination of these, as 
dictated by the control statements. 


Figure 2-1 illustrates that the librarian can process modules to or from any kind of 
storage device. The librarian can also print a librarian map that lists the control 
statements executed in the job and any listings requested by the control statements. 


This section describes the structure of the SAT and MIRAM libraries. It also gives an 
overview of the capabilities of the two librarians and the job control required to run 
them. Section 3 describes the function and syntax of all the librarian control 
statements available for each librarian. Sample librarian jobs are also included in 
Section 3. 


Canned librarian job control streams are available in the system to process modules 
and files on the system release volume. These are described in 3.5 and Appendix A. 
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Figure 2-1. Librarian Input/Output Capabilities 





2.2. SAT Librarian Capabilities 


The SAT librarian (LIBS) is a utility program used to maintain both system and user 
SAT libraries. A SAT library is a collection of program files. Each file can contain any 
assortment of program modules. A program module is made up of either source, 
macro, jproc, object, or load code. The most commonly used system libraries are 
$Y$LOD, $Y$OBJ, $Y$SRC, $Y$MAC, $Y$JCS, and the job run library $Y$RUN, 
which contains any temporary modules created by OS/3 during job execution. User 
libraries contain any program modules created and stored by the user. 

The SAT librarian can perform the following kinds of operations: 

* Copy modules from one file to another 

¢ Copy modules from one storage medium to another 

© Update existing modules in a file 

¢ Delete modules from a file 


© Correct module records 


¢ Compare modules in a file 
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a 


e =6Print listings of modules on the printer 
e Rename modules in a library file 

¢ Compress unused space in a file 

e Sequence source modules 


¢ Convert standard Ic :.d modules to blocked load modules 


2.3. SAT Library Structure 


The structure of each library depends on the characteristics of the storage medium, 
whether it be disk, tape, diskette, or cards. These are described in 2.3.1 through 2.3.4. 


2.3.1. Disk Libraries 


System and User Disk Files 


System library files reside permanently on the SYSRES volume. These files are 
created during system generation and contain all of the programs and data needed to 
run the system. Job control also creates a job run file called $Y$RUN for each active 
job in the system. The $Y$RUN file is used to process data during job execution and is 
automatically scratched when the job terminates. Therefore, any modules created in 
$Y$RUN that will be needed later should be copied to a permanent user file before the 
job terminates. Any number of additional disk files can be created by the user to store 
program modules of his choice. 


Structural Levels (Volumes, Files, Modules, and Records) 


Each disk pack is called a volume. A volume can contain any number of files, each 
with a unique file name. Each file contains modules. A module can contain either 
source, object, or load code for a program. A module can also contain a set of assembler 
macroinstructions or a job control procedure. Modules are constructed in segments 
called records. These records are variable in length and are grouped within fixed- 
length blocks. Figure 2-2 illustrates these structures. Appendix C contains ad“itional 
details about internal structure of various kinds of records and blocks. 
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VOLUME 


record 1 


FIXED-LENGTH 256-BYTE BLOCK 


Figure 2-2. SAT Library Structures 
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Disk File Space Allocation 


Each SAT file on disk has three partitions, or sections, as illustrated in Figure 2-3. 
One partition is used for a file directory. The other two partitions are data areas used 
to store program modules. When the librarian initializes a SAT file, it allocates two 
percent for the directory partition and 48 percent for the first data partition. It does 
not initially allocate any space for the second data partition. (The second partition is 
only used later if and when blocked load modules are stored in the file.) 


FILE FIRST DATA END- 
LABEL - PARTITION e OF - 
FILE 
48% LABEL 





FILE DIRECTORY 2% 


Figure 2-3. Initial SAT File Allocation 


Note that 50 percent of the file is initially unassigned. When either the directory or 
the first data partition is full and requires more space, the librarian will use some of 
this free space to extend that partition. The size of this extension will be based on the 
file extension increment specified when the file was initially allocated. When all the 
allocated file space has been used, the system will automatically extend the file by 
allocating additional free space in the same increments. This technique conserves 
space by allocating it only when needed. 


Data Records 


The data partition of a SAT file on disk contains a series of data records containing 
source, macro/jproc, object, or load code for all the modules in the file. The data 
partition also contains delimiter records which identify such things as the beginning of 
a module or a load module phase. Details on the content and format of each type of 
record are provided in Appendix B. 
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Directory Records 


For each disk file, the librarian maintains a directory it uses to locate delimiter 
records within the data area. Each directory record identifies the name, type, and 
location of its corresponding delimiter record within the data area (see Figure 2-4). 
This access method requires that each module have a unique name and type 
combination. The names in other directory entries need not be unique. 


The following kinds of delimiter records are indexed in the directory: 


Module header records 
Load module phase header records 


Note: There is a separate directory record for each phase name and each alias 
phase name. 


Macro and jproc procedure module header records 


Note: There is a separate directory record for each macro or jproc procedure 
name. 


ENTRY records for object code 
Named CSECT records for object code 
Beginning-of-group (BOG) records 
End-of-group (EOG) records 


End-of-file (EOF) record 
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DIRECTORY 
PARTITION 
FIRST DATA DELIMITER RECORD 
PARTITION 


Figure 2-4. Directory Operation 


2.3.2. Tape Libraries 


Each reel of tape of a tape library is a volume. Tape libraries have the same block and 
record format as disk libraries; however, tape libraries do not have directories. 
Modules on tape are located by reading the tape sequentially. 


2.3.3. Diskette Libraries 


For diskette libraries, each diskette is a volume. A diskette must be prepped as either 
a data set label diskette or a format label diskette (see 2.6.8 for instructions.) 


A file on a format label diskette is treated and structured like a disk file with a data 
area and a directory. Program modules stored on format label diskettes can be 
executed directly from diskette. 


A file on a data set label diskette is a sequential file like a tape file. It has a record 
size of 128 bytes. These files can be used to store backup copies of program modules; 
but the programs must be copied to format label diskettes or disks to be executed. 
Data set label diskettes can be used as a substitute for cards. 
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2.3.4. Card Libraries 


When a source module is punched on cards, each card is considered a record. Because 
card records have a fixed length of 80 characters, when a source module from another 
storage medium is punched on cards, any records having more that 80 characters will 
require more than one card. Each card should contain a sequence number so that the 
librarian can automatically check the order of the cards as it reads them. Modules that 
are not sequenced when they are originally punched can be sequenced later using the 
SEQ librarian control statement. 


When an object or load module is punched on cards, it is divided into 80-byte records 
containing a 5-byte sequence number and 75 bytes of data. When the librarian copies 
the records back to a disk or tape file, it reassembles the records as they originally 
existed in the original file. 


Data set label diskettes can be used as a substitute for cards. On these diskettes, the 
record size is 128 bytes. 


2.4. SAT File Allocation and Management 


The SAT librarian cannot allocate files. It can only manipulate existing files on disk, 
tape, or diskette. System files are automatically allocated by the system. User files 
must be allocated explicitly. A user file on disk or format label diskette must be 
allocated by either an // EXT job control statement or the interactive services 
ALLOCATE command. The file type must be ST for SAT. A tape file or data set label 
diskette is essentially allocated when it is prepped. 





Once a file has been allocated, modules can be stored in it. The entire contents of the 
file can then be copied to any other storage medium, compared with another file, 
deleted, or compressed using the librarian. The librarian can also be used to print a 
file directory or listing. 


2.5. SAT Module Creation and Management 


2.5.1. Module Types 


A module is a set of one type of code for one program. There are four types of program 
code: program source, macro/jproc source, object, and load. The module type refers to 
the type of code a module contains. A single file can contain modules of assorted types 
arranged in any order. 
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2.5.2. General Module Operations 


Many librarian operations can be applied to one or more modules at a time, as 
specified through options and parameters in the librarian control statements. For 
example, an operation can apply to one module, all modules with a certain name 
prefix, all modules of a certain type, or a series of consecutive modules within a file. 
Module groups containing any assortment of modules can also be processed 
collectively in group operations. 


All types of modules can be copied to another file or be renamed. However, librarian 
operations that change the content of the module itself may be restricted to certain 
types of modules. The following sections explain the restrictions on each type of 
module and on module groups. 


2.5.3. Program Source Modules 


A program source module is a set of program source statements written in a 
programming language such as COBOL or RPG II. A job control stream is also 
considered a source module. 


Program source modules can be created interactively at a workstation using the 
general editor (EDT) or a specialized subeditor of EDT, such as the RPG II editor or 
the COBOL editor. These modules can then be copied to tape, disk, or diskette 
through the use of the EDT @WRITE command. They can also be punched on cards 
through the use of the EDT @PUNCH command. Source modules can also be created 
on punched cards by using coding forms and a keypunch. 


Once a program source module has been created, it can be copied, deleted, listed, 
resequenced, compared, punched, or renamed using the librarian. The librarian can 
also be used to change, delete, add, or resequence records within a source module. 


2.5.4. Macro and Jproc Source Modules 


A macro source module contains a series of assembler macroinstructions and 
directives used as input to the assembler. A jproc (or proc) source module contains a 
series of job control statements and directives that make up a job control procedure. 
All of the librarian operations that can be used on program source modules can also be 
used on macro and jproc source modules. 


The librarian identifies both macro and jproc source modules as macro source modules 
in the file directory. Therefore, a macro source module and a jproc source module with 
the same name may not exist in the same disk file. 


Each macro and jproc source module may be referenced by more than one name. In 
this case, the directory contains a separate record for each additional name. There can 
also be more than one directory record specifying the same name. However, each 
directory record will reference the same location for the module in the data area. 
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In librarian control statements, the module type M is used to refer to macro, proc, or 
jproc source modules. 


2.5.5. Object Modules 


When a source program is compiled by its appropriate language compiler, the output 
of the compiler is an object module. This object module can then serve as input to the 
linkage editor. 


The job control statements used to compile the source program specify the output file 
where the object module is to be stored. The output file can be the job run file 
$Y$RUN, the $Y$OBJ system file for object modules, or any user file. The $Y$RUN 
file is scratched at the the end of job execution, so the object module is only saved 
permanently if another output file is specified. 


Object modules can be copied, deleted, compared, punched, listed, renamed, and 
patched using the librarian. COM, ENTRY, CSECT, V-CON and EXTRN records’ 
within object modules can also be renamed. The librarian can also be used to insert or 
delete linkage editor control statements in an object module. 


Whenever object modules are serviced by the librarian, they are checked for proper 
content and record sequence. Discrepancies trigger diagnostic processing. 


All object modules produced by the various language compilers are assumed to be 
nonsharable (nonreentrant) modules. However, sharable (reentrant) modules may be 
flagged by the librarian to enable them to produce sharable (reentrant) load modules 
when they are link-edited. 


2.5.6. Load Modules 


When an object module is processed by the linkage editor, the output is a load module, 
which is a program in executable form. Part 3 of this guide explains how to use the 
linkage editor. A LINK jproc call statement that executes the linkage editor is 
described in the Job Control Language Programming Guide (UP-9986). 


The // PARAM or // LINKOP control statements used in the linkage editor job step 
specify the output file where the load module is to be stored. The output file can be the 
job run file $Y$RUN, the $Y$LOD system file for load modules, or any user file. The 
$Y$RUN file is scratched at the the end of job execution, so the load module is only 
saved permanently if another output file is specified. 


Load modules can be copied, deleted, compared, punched, listed, and renamed using 
the librarian. The librarian can also be used to patch load modules. Patches are 
inserted at the end of a specified phase, which is a portion of a load module that is 
loaded into main storage at one time. 
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Each phase in a load module is given a name at link-edit time. This name can be 
supplied automatically by the linkage editor or explicitly by the programmer. The 
programmer may also assign each phase an additional alias-phasename to be used to 
reference the phase in program subroutines. Alias-phasenames can be changed using 
the librarian. 


Most load modules produced by the linkage editor can be converted to blocked load 
modules by the librarian. Blocked load modules can usually be loaded for execution 
faster than their unblocked versions. Exceptions to this are explained in the 
description of the BLK librarian control statement (see 3.3.13). 


2.5.7. Module Groups 


The librarian can process modules in groups. A group is a consecutive series of 
modules within a file. It can contain any number of modules of assorted names and 
types. When a module group is created through the librarian, it is given a group name 
that is used to reference the entire group of modules so that they can be processed 
collectively. For example, an entire group of modules can be copied or deleted with one 
librarian control statement that references the group name. The librarian can also be 
used to change the group name. More information on creating and processing module 
groups is given in 3.3.18. 


2.5.8. Module and Group Header Records 


The first record in each module is a module header record that identifies the module 
type, name, date and time of creation, and any comments the user includes. When a 
librarian job is run, this header information is printed on the librarian map to verify 
which modules were processed by each operation. Similarly, each module group within 
a file begins with a module group header record that identifes the name of the group 
and an optional comment. In disk files, all module header records and group header 
records are indexed in the file directory to help the librarian locate them when needed. 


2.5.9. Naming Conventions 


Module Names 


Each module within a library file has a name assigned by the user. This name can 
contain up to eight characters, including letters, digits, &, $, ?, or #. If the name 
assigned to a source or object module contains less than eight characters, it is left- 
justified and padded with blanks to the right. A load module is padded with zeros. 
Modules are named when they are created, as follows: 

¢ Assembly or compile time for object modules 


e _ Link-edit time for load modules 
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¢ Allocation time for program source modules 
¢ Job run time for macro and jproc source modules 
A module can be renamed by using the REN librarian control statement. 


See 2.5.4 for more information about naming macro and jproc source modules. 


Module Group Names 


When a module group is created, it is given a name containing up to eight characters, 
including letters, digits, &, $, ?, or #. This group name is independent of the individual 
module names within the group. It is used only to refer to all modules in the group at 
once, never part of the group. 


A group name need not be unique. The use of options and parameters in the librarian 
control statements can specify all groups with a certain group name, only the next 
group with a certain group name, or all groups with a certain name prefix. Every 
module in a disk file must still have a unique name and type combination, even if they 
are in different groups within the file. 


A group name may be changed by using the REN librarian control statement. 





Name Prefixes 

Librarian control statements that allow the C option can process all modules or groups 
with the same name prefix. Thus, related modules or groups can be given related 
names and then be processed together. Any consecutive series of characters from the 
beginning of a module or group name can be treated as a prefix. All of the following 
module names have the name prefix COB: 


COBACCT 
COBMAST 
COBSRC43 
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@ 2.6. Using the SAT Librarian 


2.6.1. Basic Job Control for the SAT Librarian 


The following is a sample job control stream used to run the SAT librarian. For more 
information on job control, see the Job Control Language Programming Guide 





(UP-99886). 
1. // 3sOB SAMPLE 
2.| // DVC 20 // LFD PRNTR 
3.1 // DVC 40 // LFD PUNCH 
4.| // DVC 5@ // VOL DSKG@1 Device assignments 
5.| // LBL DISKFILE // LFD DISK1 depend on devices and 
6.| // DVC 108 // VOL TAPOQ1 files required for job 
ie // LBL TAPEFILE // LFD TAPE1 
8. // EXEC LIBS 
9.1 /% 
Librarian control statements 
10|. /* 
11}. /& 


1. The// JOB statement names the job SAMPLE. This statement can also 
specify additional main storage to improve the performance of the librarian 
(see 2.6.5). 


2. This is the device assignment set for a printer that is needed to print the 
librarian map. If a printer is not assigned to the job, the // PARAM 
PRINT=OFF statement must be used to suppress printing of the librarian 
map (see 2.6.3). 


3. through 7. 
These are device assignment sets for the devices and files required for the 
job. These will vary with each job. In this case, line 3 is a device assignment 
set for a card punch. Lines 4 and 5 are a device assignment set for one disk 
file. Lines 6 and 7 are a device assignment set for one tape file. 


For each disk, tape, and diskette file, the name following the // LBL is the 
name of the file as recorded on the storage medium. The logical file 
descriptor (LFD) is the name given to the file within the program. In the 
librarian job step, FIL librarian control statements equate each LFD with a 
logical file name that is then used in subsequent librarian control statements 
to reference that file. 


For more information on device assignment sets, see the Job Control 
Language Programming Guide (UP-9986). 
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8. 





The // EXEC LIBS statement executes the SAT librarian called LIBS. 


9. and 10. 


11. 


The /$ indicates the beginning of the librarian control statements that 
describe the librarian functions to be performed. The /* indicates the end of 
the librarian control statements. 


The /& indicates the end of the job. 


Notes: 


1, 


All statements from the | / EXEC LIBS statement to the /* statement, 
inclusive, comprise a separate job step that executes the librarian. Therefore, 
other job steps could be inserted in this job between the device assignment 
statements and the / / EXEC LIBS statement or between the /* and the /& 
statements. 


When librarian job control stream is created on punched cards, a | / FIN job 
control statement is required after the / & end-of-job statement to end the card 
reader operation. 


A sample session illustrating the use of the general editor (EDT) to create and 
run a librarian job interactively is given in 3.6.1. 


A single librarian job can process any number of files. However, the @ 
maximum number of files that can be open at one time is six. See 3.3.1 for 
more information. 


The job run file $Y$RUN can be processed in the same way as any other file 
and be declared in the FIL librarian control statement. Even if it is not 
declared in the FIL statement, the $Y$RUN file can still be used by default in 
some librarian control statements. No device assignment set is required for 
$Y$RUN. 


A program should not be executed while it is being restored, updated, or 
punched on cards. 


2.6.2. Error Handling 


2-14 


Error Messages 


Normally, when the librarian encounters an error in processing a control statement, it 
prints an error message on the librarian map and terminates the execution of that 
statement. Each error message contains an error number and a brief error description. 
More detailed error descriptions and corrective actions are contained in the current 
version of the System Messages Reference Manual (UP-8076). 
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Stopping or Canceling the Job (// PARAM ERROR) 


Normally, if an error is not critical, the librarian will continue to process subsequent 
librarian control statements in the job step. There are two // PARAM statements that 
can be used to stop execution of the librarian when an error occurs. 


// PARAM ERROR=STOP ends the librarian job step when an error is encountered in 
the librarian control statements. Subsequent librarian control statements are not 
executed. However, the UPSI bytes are set and the librarian job step terminates 
normally. Also, any subsequent job steps are executed. 


// PARAM ERROR=CANCEL causes immediate abnormal termination of the job in 
the event of an error, with abnormal termination of the librarian job step. No 
subsequent job steps are executed. This can be used by Unisys systems analysts to 
document librarian processing problems. 


Only one of these statements should be used in a job. If used, it must be placed 
between the // EXEC LIBS and the /$ job control statements. 


2.6.3. Librarian Map 


Description 


Each time the librarian is executed, it can produce a librarian map containing the 
following information: 


¢ All librarian control statements in the order that they were processed. Each 
control statement is identified with the label COMMAND . 


¢ Header information for all modules processed by each statement (unless the N 
option is used) including module flags set by the librarian for internal use only. 
(They are: R, reentrant module; B, base0 module; K, keyO module; C, module has 
been corrected.) 

e Any error messages caused by each librarian control statement. 

¢ Any module listings requested by each librarian control statements. 

¢ All records added, deleted, or changed during module correction operations. 


e Any discrepancies found during module or file compare operations. 


Sample librarian maps are provided with the SAT librarian job examples in 3.6. 
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Suppressing the Librarian Map (// PARAM PRINT=OFF) 


If a printer device is assigned to the librarian job, the librarian produces a librarian 
map automatically. When a librarian map is not needed, the following job control 
statement must be used to suppress the printing of the librarian map: 


// PARAM PRINT=OFF 


If used, this must be the first // PARAM statement in the librarian job step. It must be 
placed immediately after the // EXEC LIBS job control statement and precede the /$ 
job control statement. This statement suppresses the printer for the duration of the 
librarian job step only. After that, any printer declared in a device assignment set is 
still available for other job steps. 


If this job control statement is used when a printer is not assigned to the job, a DM03 
error is returned. 

Printing Source Modules in Hex Format (// PARAM PRTOBJ=ON) 

Whenever program source or macro/jproc source modules are printed on the librarian 
map by a COP statement or a D option, they are printed in EBCDIC exactly as they 
were coded. To print them in hex format instead, include the following statement after 


the // EXEC LIBS statement and before the /$ job control statement in the librarian 
job control stream: 


// PARAM PRTOBJ=ON 


This parameter remains in effect for the entire librarian job step. 


2.6.4. Specifying the Date and Time of Module Creation 
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(// PARAM UPDATE) 


Each module header record contains the date and time that the module was created, 
corrected, or updated. When the librarian corrects or updates a module, it normally 
obtains this date from the system information block while the librarian job is being 
executed. 


The // PARAM UPDATE statement can be used to set a different date and time to be 
in effect for the duration of the librarian job only. If used, it must be placed between 
the // EXEC LIBS and the /$ job control statements. The // PARAM UPDATE 
statement has the following format: 


// PARAM UPDATE=yymmdd/hhmm 


The value used for yymmdd/hhmm represents the date and time in the form year, 
month, day, slash, hour, minute. 
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2.6.5. Allocating Additional Main Storage 


Execution time for a librarian job can be reduced by allocating additional main storage 
space for the job in the // JOB job control statement. This additional space is allocated 
in track-sized buffers. To determine the amount of main storage to allocate, compute 
the number of buffers needed using the following recommendations: 


e = Specify at least two buffers for disk access (four or more is optimal). 


e Add one more buffer for each diskette or variable block tape used (one for each Tn 
file declared in the FIL librarian control statement). 


¢ Allocate additional main storage for ESC processing (see Table 2-1). 


The second positional parameter in the // JOB statement must specify the amount of 
additional main storage in decimal or hex bytes, as shown in Table 2-1. For example, 
each of the following // JOB statements allocate enough main storage for the librarian 
base plus one buffer: 


// JOB SAMPLE, ,B62@ 
// JOB SAMPLE, ,X'B620! 
// JOB SAMPLE, ,D'46624! 


& Table 2-1. Additional Main Storage Requirements for Using the SAT Librarian 
Buffer Requirements Hex Bytes 
Librarian base 34,304 8600 
ESC processing 29,696 7400 
1 buffer 46,624 B620 
2 buffers 62,528 F440 
3 buffers 78,432 13260 
4 buffers 94,336 17080 
5 buffers 110,240 1AEAO 
6 buffers 126,144 1ECCO 
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2.6.6. Processing Disk Files 


The following notes apply to the librarian processing of disk files: 

e Adisk volume may contain more than one file. 

¢ Each module must have a unique name and type combination. 
* Modules are located using a file directory. 

¢ Modules and files can be deleted. 


¢ Modules are updated by deleting the old version and adding the new version to 
the end of the file. 


e Files are extended automatically by the system, when necessary. 


¢ Files can be compressed to obtain contiguous space at the end of the file. 


2.6.7. Processing Tape Files 
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Librarian Restrictions for Tape Files 

In general, any librarian operation that alters the original file or processes the file 

directory cannot be performed with a tape file. These operations, and their associated 

control statements, include: 

¢ Blocking load modules (unless the blocked version is output to disk) 

¢ Deleting modules and files (DEL) 

© Compressing files (PAC) 

e Listing the file directory (LST) 

¢ Renaming files and modules (REN) 

¢ Sequencing modules (SEQ) 

Other points to remember when using tapes are the following: 

e A tape file may contain more than one module with the same name and type. In 
this case, when a librarian control statement references a module by name and 


type, the librarian processes the next one it encounters with that name and type. 


¢ Modules are located by reading the tape sequentially from the pointer position 
and rewinding the tape, if necessary. 


¢ New modules are added at the end of a tape file. 
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¢ Amodule on tape cannot be updated; however, a new version of the module can 
be copied to the same tape and be given the same name and type as the original. 


¢ Amodule cannot be deleted from a tape file; however, a tape file may be edited by 
selectively copying the modules to be saved from the original tape to a new tape. 


Note: The librarian will only support multiblock tape files, or variable block tape 
files, if the system supports consolidated data management (also called CDD or 
mixed mode. Mixed mode includes both consolidated data management and 
basic data management (also called DTF). If the system supports DTF only, 
multiblock tape files are not supported by the librarian. 


Prepping Tapes 


Each tape must be prepped before any data can be stored on it. This can be done by 
using either the PREP option in the // VOL job control statement or the tape prep 
routine (TPREP) described in Section 11. 


Note: When the PREP option is used in the / | VOL job control statement, the tape is 
prepped each time it is opened as an output file. Therefore, if the tape is used as 
both an input and an output file in a single job, every time the file is reopened 
as an output file, all data on the tape as a result of previous operations will be 
overwritten. This prevents the continuous accumulation of data on the tape 
during the course of a job step. To avoid this problem, the tape should be 
prepped in a separate job step or through TPREP. 


Header and Trailer Labels 


Tape libraries must have standard header and trailer label records. The name 
specified in the // LBL job control statement must agree with the file 2 label in the 
tape library. See the current version of the Consolidated Data Management 
Programming Guide (UP-9978). 


Optional Block Length Selection 
Tape libraries use the same block and record format as disk libraries. There is, 
however, an option of specifying a block length other than the default length of 256 
bytes. To do this, include the following job control statement in the device assignment 
set for the tape file (between the // VOL and // LBL statements): 

// DD BKSZ=n 


This statement tells the librarian to produce an output block or expect an input block 
of the size specified. The following rules apply: 


¢ The value n must be a multiple of 256. 
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¢ The maximum value allowed for n is 8192. 


¢ For an input tape, n must be at least as large as the value used when it was 
created. 


For a complete description of the BKSZ parameter, see the Consolidated Data 
Management Programming Guide (UP-9978). 


When processing tapes with variable-length blocks, one additional buffer of main 
storage space should be allocated for each tape in the job. This space is needed for 
processing operations and for I/O buffers (see 2.6.5 for instructions). 


Creating a Multifile Tape (// PARAM TAPEFILES=MULTI) 


The following // PARAM statement allows the librarian to output more than one file to 
a single-tape volume: 


// PARAM TAPEFILES=MULTI 


If used, this statement must be placed between the // EXEC LIBS statement and the 
/$ job control statement. If this statement is not used, only one file can be be written to 
a tape. This statement is not required to read a file on a multifile tape. 


A multifile tape is created by copying files from another storage medium to output 
files on the tape. The tape must already be prepped and it may or may not already 
contain some files. The files must be copied in sequence as they are to be arranged on 
the tape. These files cannot be extended later. 


The librarian job, which copies the files to the tape, must contain the // PARAM 
statement. Also, the // LBL job control statement for each new tape file must include a 
file sequence number parameter (in positional parameter 4) to indicate the position of 
the output file on the tape. For example, if the tape already contains two files, the // 
LBL statement for the first new tape file must specify a 3 for the file sequence 
number. If the tape is a newly prepped tape that does not yet contain any files, the file 
sequence number for the first new tape file must be 1. 


As the files are being output to the tape, only one tape file can be open at a time. 
Therefore, the librarian job step should use the same logical file name (Tn) for every 
tape file, but redefine that logical file name each time a new file is to be processed. 
(See the FIL librarian control statement description for more information.) 


Normally, after each file is written to the tape and then closed, the librarian would 
rewind the tape to the load point. Then it would reopen the tape and advance to the 
end of the tape again to write the next file. However, a // DD job control statement 
with a rewind parameter can be used in the device assignment set for each tape to 
eliminate unnecessary rewinding at each open and close operation. 
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; ¢ The statement // DD OPRW=NORWD specifies no rewind at file open. 


¢ The statement // DD CLRW=NORWD specifies no rewind at file close. 


Specifically, the device assignment sets for the tape files should specify 


¢ CLRW=NORWD for the first tape file 


¢ OPRW=NORWD for the last tape file 


¢ Both OPRW=NORWD and CLRW=NORWD for all other files 


The following sample job copies five files from disk to the same new tape volume: 


// JOB 
// bvC 
// bve 
// ove 
// bvC 
// bvC 
// DVC 
// ove 
// LBL 
// bvC 
// LBL 
®@ ae 
// LBL 
// OVC 
// LBL 
// Ove 
// LBL 


MULTFILE 


2@ // LFD PRNTR 


5@ // VOL 
5@ // VOL 
5@ // VOL 
5@ // VOL 
58 // VOL 
98 // VOL 
TFIL1,,,.1 
98 // VOL 
TFIL2,,,,2 
98 // VOL 
TFIL3,, 543 
98 // VOL 
TFILS,,,,4 
98 // VOL 
TFIL5, 5,45 


// EXEC LIBS 
// PARAM TAPEFILES=MULTI 


/$ 


/* 
/& 
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DQ0410 
DQ04 10 
000410 
000410 
DGG410 
$01841 
// LFD 
$01841 
// LFD 
$01841 
// LFD 
$01841 
// LFD 
$01841 
// LFD 


// LBL DISKFIL1 // LFD DISK1 
// LBL DISKFIL2 // LFD DISK2 
// LBL DISKFIL3 // LFD DISK3 
// LBL DISKFIL4 // LFD DISK4 
// LBL DISKFIL5 // LFD DISKS 
// DD CLRW=NORWD 

TAPE1 

// DD OPRW=NORWD, CLRW=NORWD 
TAPE2 

// DD OPRW=NORWD, CLRW=NORWD 
TAPES 

// DD OPRW=NORWD, CLRW=NORWD 
TAPES 

// OD OPRW=NORWD 

TAPES 


FIL D@=DISK1, TO=TAPE1 
COP @,,,T@ 
FIL D@=DISK2, T@=TAPE2 
CoP @,,,10 
FIL D@=DISK3, T@=TAPES 
cop D@,,,T@ 
FIL D@=DISK4, TO=TAPEG 
cop De,,,T@ 
FIL D@=DISK5, TO=TAPES 
COP De,,,T8 
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2.6.8. Processing Diskette Files 


Before a diskette volume can be used, it must be prepped in either data set label or 
format label mode. A diskette that has been prepped in data set label mode will be 
treated as a tape volume (see 2.6.7 for restrictions). A diskette that has been prepped 
in format label mode will be treated as a disk volume. The librarian operations 
permitted for the diskette are then determined accordingly. 


For a diskette file, the // DVC job control statement must specify a logical unit number 
of 130 through 159. The logical file name assigned in the FIL librarian control 
statement specifies the kind of diskette by using a (Tn) keyword parameter for a data 
set label diskette and a (Dn) keyword parameter for a format label diskette. 


When processing diskette files, the allocation of one additional buffer of main storage 
space will improve the performance of the librarian. See 2.6.5 for instructions. 


Single-device, multivolume SAT files cannot be copied to diskette. 


2.6.9. Processing Card Libraries 


2.6.10. 
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When a librarian job is going to produce output on punched cards, the job control 
stream must contain a device assignment set for a card punch, for example, 


// OVC 48 // LFD PUNCH 


On cardless systems, output can be written to a data set label diskette instead of to 
cards. 


Current File Position Pointer 


The librarian maintains a pointer in each file it processes. The modules processed by 
each librarian control statement depend on the options and parameters used in the 
control statement and the current pointer position in the input file being processed. 
When a file is opened, the pointer is at the beginning of the file. 


A control statement may process one particular module or module group or all 
modules that meet certain criteria, such as a particular name, type, or name prefix. To 
process only one particular module, a control statement must include the module 
name and type. To process only one particular group, the control statement must 
include the group name and the G option. After the control statement is executed, the 
pointer remains after the module or group processed. 


To locate a particular module or group, the librarian searches the file starting from 
the current position in the file and wraps around to the beginning of the file, if 
necessary. For disk and format label diskette files, the librarian searches the file 
directory. For tape and format label diskette files, it searches the file sequentially. If 
the librarian cannot locate the particular module, it prints an error message on the 
librarian map and then processes the next librarian control statement starting from 
the same position within the file. 
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To process all modules that meet certain criteria, the control statement must include 
or omit certain options and parameters. Variations are listed in Table 2-2. In this case, 
the librarian searches the file for modules that meet these criteria. It always begins 
the search at the current position in the file. If the U option is not used, it ends the 
search at the end of the file. In this case, after the control statement is executed, the 
current position is then at the beginning of the file. If the U option is used, the search 
ends after a particular module or group and the pointer remains there for the start of 
the next operation. 


When modules are copied to or placed in an output file, modules are always placed at 
the end of the file. 


Should it be necessary to reset the pointer to process a particular module or range of 
modules in a file, there is a RES librarian control statement to do this (see 3.3.2). 


Table 2-2. Control Statement Requirements for Processing Selected Modules 
Requirements 
Type 
No 


Yes 







Modules to Be Processed 





All modules with a given name 







All modules of a given type 


& All modules 












All modules with a given name prefix Module prefix C 
All modules with a given name prefix and type Module prefix C 
All modules in the next group with a given name Group name G 
Ali modules in all groups with a given name Group name GA 
All groups with a given name prefix Group prefix GC 
All modules from the printer position up to Module name U 
and including a particular module 

All modules from the pointer position up to Group name GU 








and including the next group with a given name 
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2.6.11. 


2.6.12. 
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Assigning Version Numbers to SAT Library Modules 


To minimize errors in the correction process for SAT library modules, version numbers 
are assigned to all modules. The first time the librarian copies a module, it expands 
the header for that module to include a version field. This field consists of three 
subversion fields in the form of n/n/n where the value of n is a decimal number from 0 
to 255. The initial number assigned by the librarian is 0/0/0. The assigned version 
number remains unchanged until you update it. To assign or change the version 
number of a SAT library module, use one of the following statements: 


//PARAM VERASG=n/n/n 
Specify in your job stream prior to the // EXEC LIBS statement. Specifies the 
version number n/n/n assigned to module copied or created by the librarian. 


LIBOP VERASG=n/n/n 
Specify prior to accessing the library module via a COP, COR, or BLK 
statement. Specifies the version number (n/n/n) assigned to a module copied 
or created by the librarian. : 


cop 
COR 
BLK} ,...,VERASG=n/n/n 


Specify when you want to assign a version number as part of the operation 
specified by the individual command. 


You have the option of specifying one, two, or all three subversion numbers. You 
cannot omit one subversion number and specify the next. 


When correcting a module, you can identify the specific module you want corrected by 
specifying its version number on the appropriate COR command statement (see 
3.3.10). A comparison is made of the version numbers specified and the version 
numbers of the module being corrected. If they do not match, a diagnostic is printed 


and the correction process is terminated. Only the version numbers specified are 
compared; all other levels are ignored. 


Printing Library Module Fields before Correction 
(// PARAM PRTCOR) 


Before correcting a field in a SAT librarian object or load module, you can verify its 
contents by having the librarian print an image of that field. To turn on this librarian 
feature, specify either: 
// PARAM PRTCOR=ON 
or 


LIBOP PRTCOR=ON 


When omitted, the print-before-correction-image feature is turned off. 
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2.7. MIRAM Librarian 


2.7.1. MIRAM Librarian Capabilities 


The MIRAM librarian is used to maintain the following types of modules: 

¢ Screen format modules 

¢ Help screen modules 

e Saved run library modules 

¢ Menu modules 

The librarian operations available for MIRAM libraries are limited to the following: 
© Copy modules from one file to another 


© Delete modules from a file 


Print listings of modules and file directories 
e Change a module name 


e Change comments in a module header record 


2.7.2. MIRAM File Allocation and Management 


The MIRAM librarian can only be used to manipulate files once they exist on disk, 
tape, diskette, or punched cards. The user may allocate a MIRAM file by using either 
the // EXT job control statement or the interactive services ALLOCATE command. The 
file type must be MI for MIRAM. A MIRAM tape file is essentially allocated when it is 
prepped. 


Once a MIRAM file has been allocated, modules can be stored in it. The entire file can 
also be copied or deleted using the MIRAM librarian. The librarian can also be used to 
print a file directory. 


2.7.3. MIRAM Module Structure 


A MIRAM module consists of a set of code that is executed at run time. Each module 
begins with a header record that is formatted as described in Table 2-3. 
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Table 2-3. MIRAM Module Header Record Format 





811 


12-14 


1517 


18-19 


20-23 


24-27 


28-30 


31 





2.7.4. MIRAM Module Creation 





Module name 
Module type 
Creation date (yymmdd) 

Creation time (hhmmss) 

Number of active bytes in the last sector occupied by the module 
Number of data sectors 

Total number of sectors occupied by the module 

Reserved for flags 

Active flag: 


X00’ - Delete module 
XFF’ - Active module 





Record size 


Screen format modules contain formatted display screens that are used to supply 
input and display output at workstations for user application programs. Users create 
screen format modules by running the screen format generator (SFG) program. 


Each time a screen is generated by SFG, two screen format modules are produced. 
Both modules have the same name, but one is type FC and the other is type F. The 
type FC module contains the screen format text that is displayed at the workstation 
when the screen format is used in an application. The type F module contains the 
control information needed to handle the flow of data passed to and from the 
application via the screen format. 
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Help screen modules are provided with the system in the system file $Y$HELP. The 
user can create additional help screens using the general editor (EDT). Once created, 
these screens must be saved in the system file $Y$HELP as type H B084 modules 
using the general editor @WRITE command. 


Saved run modules are translated job control streams saved in the system file 
$Y$SAVE through the job control SAVE option. 


Menu modules are created by the menu processor. Refer to the Menu Services 
Technical Overview (UP-9317). 


2.7.5. MIRAM Module Management 


The MIRAM librarian provides control statements to copy modules, delete modules, 
print listings of modules, change a module name, and change a comment in a module 
header record. All MIRAM librarian control statements can be used for any type of 
module. The use of various options and parameters in the control statements allow the 
librarian to process one module or all modules in a file with the same name, name 
prefix, or type. , 


2.7.6. Using the MIRAM Librarian 


The following is a sample job control stream used to run the MIRAM librarian. For 
more information on job control, see the Job Control Language Programming Guide 
(UP-9986). Figure 2-5 is the librarian map generated by this example. The librarian 
map lists the volume and actual file labels for files declared on the FIL statement. 


1 18 16 72 





1. |// JOB MLIBRUN 

2. |// DVC 20 // LFD PRNTR 

3. |// OVC RES // LBL $YSFMT // LFD IN 
4. |// DVC 138 // VOL 007041 

5. |// EXT MI,C,2,CYL,2 

6. |// LBL SCREEN // LFD SCRN 

7. |// EXEC MLIB 

8. {s/s 

9. FIL FQ=IN,F1=SCRN 

10. COP F,F,SFGSCRN,F1 

11. COP F@,FC,SFGSCRN,F1 

12. COP.C F@,F,SFSPL,F1 

13. COP.C F@,FC,SFSPL,F1 

14. COP FO,MENU, ,F1 

5. PRT.D F1 

16. GHG -F1,F, SFSPLIO,N, SESXXXX 
7. CHG F141, F,SFSXXXX,C, "NAME CHANGE! 
18. DEL.C F1,MENU,0S31 

19. PRT.D F1 

20. |/* 

21. |/& 
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The // JOB statement names the job MLIBRUN. 


This is the device assignment set for a printer that is needed to print the 
librarian map. If a printer is not assigned to the job, or a librarian map is not 
required, the // PARAM PRINT=OFF statement must be used to suppress 
printing of the librarian map (see 2.6.3). 


This is a device assignment set for the system file $Y¥$FMT on the SYSRES 
volume. This file is given the logical file descriptor of IN, which is then 
equated to a logical file name F0 in the FIL librarian control statement 
(line 9). This logical file name is then used to reference the file in all 
subsequent librarian control statements (lines 10 through 19). 


4, through 6. 


This is the device assignment set to allocate a diskette file named SCREEN 
on the diskette volume D07041. This file is given the logical file descriptor of 
SCRN, which is then equated to the logical file name F1 in the FIL librarian 
control statement (line 9). This logical file name is then used to reference the 
file in all subsequent librarian control statements (lines 10 through 19). 


Initiates execution of the MIRAM librarain. 
Identifies the beginning of the librarian control statements. 
The FIL librarian control statement assigns a logical file name to each file 


used in the job. These logical file names will be used exclusively to reference 
these files in subsequent librarian control statements. 


10. through 14. 


15. 


16. 


These COP librarian control statements copy the following modules from the 
file $Y$FMT to the file SCREEN: 


e ©The type F screen format module named SFGSCRN 

¢ The type FC screen format module named SFGSCRN 

¢ All type F screen format modules with names beginning with FSPL 

e All type FC screen format modules with names beginning with SFSPL 
¢ All menu modules 


This PRT librarian control statement prints an alphabetical listing of header 
records for all modules now in the file SCREEN. 


This CHG librarian control statement changes the name of the type F screen 
format module SFSPLIO to SFSXXXX. This module is in the file SCREEN. 
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17. 


18. 


19. 


20. 


21. 


This CHG librarian control statement inserts the comment ‘NAME 
CHANGF ’ in the header record for the type F module that is now named 
SFSXXXX. 


Deletes all menu modules in the file SCREEN with names beginning with 
the prefix 0S31. 


This PRT librarian control statement prints an alphabetical listing of all 
module header records in the file SCREEN. This list can be compared to the 
list produced by line 15 to verify that the changes and deletions specified by 
lines 16 through 18 were made. 

Identifies the end of the librarian control statements. 


Identifies the end of job. 


Notes: 


1. 
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All statements from the | / EXEC MLIB statement to the /* statement, 
inclusive, comprise a single job step. Therefore, other job steps could be 
inserted in this control stream between the device assignment statements and 
the | / EXEC MLIB statement or between the /* and the /& job control 
statements. 


When a librarian control stream is created on punched cards, a | / FIN job 
control statement is required after the /& job control statement to end the card 
reader operation. 


A sample session illustrating the use of the general editor (EDT) to create and 
run a librarian job control stream interactively at a workstation is given in 
3.6.5. 

The device assignment sets vary depending on the files being processed. 


A device assignment set for a system file on the SYSRES volume must include 
an // LBL statement. 


When MIRAM files on format label diskettes are being processed, all volumes 


must be mounted for the duration of the job step. Only one data set label 
diskette volume can be processed at a time. 
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OE-~ 


b AY THBSdN 





UNISYS OS/3 MIRAM LIBRARIAN 
DATE 88/05/14 TIME 18.39 


4% 

FIL 
cop 
CoP 


cop 


ORT 


CHG 
CHG 
DEL 


PRT 


/* 


LIBRARIAN FINISHED 
DATE 88/05/14 TIME 18.41 


MLO24 


MLIB TOTAL ERRORS= 


JOB 


2C 


eae) 


oC 


2D 


oooo0, 





MLIBRUN 


FOZIN,FI=SCRN 
FO,F »SFGSCRN,FI 


FO,FC,SFGSCRN,FI 


FO,F,SFSPL,FI 
FO,FC,SFSPL,F 


FO,MENU,,FI 


Fl 


Fl, Fy SFSPLIO,Ny SF SXXXX 
FL,&ySFSXXXX,C, "NAME CHANGE ®* 
F1,MENU,OS31 


Fi. 


NAME CHANGE 


uPsI= x*go°* 


Figure 2-5. Sample MIRAM Librarian Map 


FC 
Pe 


MEN) 
MENID 
MENU 
MENU 


MENU 
MENU 


MENU 


MENU 
MEN 


Fe 


FC 
FC 


SFGSCPRN 
SFGSCRN 


SF SPLINF 
SFSPLIO 


SF SPLINE 
SFSPLIO 


9S$3N1 
9S 302 
9s3i148 


9s3ni 
0$ 302 
98314 
SFSSCRN 
SFGSCRN 
SF SPLINE 
SF SPLINE 
SFSPLIO 
SFSPLIO 


98314 


$301 

98302 

SFGSCRN 
SFGSCRN 
SFSPLINF 
SF SPLINE 
SFSPLIO 
SF SXXXX 


RAZ11/14 
80/11/14 


nn7no/on 
s0/N172n 


09790700 
89701729 


AN/NBs21 
B0/9A721 
8N/NA/ 21 


9n708721 
AN/08/21 
BO/IA/21 
BO/11/18 
AN/LIs14 
ensnnvon 
o979N/N0 
Ansnis20 
81/01/26 


snsNas2y 


§9/NB/21 
en/nss2)i 
ans11s/148 
80/11/14 
on/noson 
oosnoson 
89/01/20 
sa/nls2n 





20.36 
270.36 


c0.17 
18.30 


cO.17 
28.30 


14.30 
25212 
14.40 


14.30 
15.12 
34.40 
20.36 
20.36 
cO.17 
c0.17 
38.30 
18.30 


14.49 


14.30 
15212 
20.36 
20.36 
c0.17 
90.17 
28.30 
18.30 
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@ 2.7.7. Creating a Multifile Tape (// PARAM TAPEFILES=MULTI) 


The following // PARAM statement allows the librarian to output more than one file to 
a single-tape volume: 


// PARAM TAPEFILES=MULTI 


If used, this statement must be placed between the // EXEC MLIB or // EXEC LIBS 
statement and the /$ job control statement. If this statement is not used, only one file 
can be be written to a tape. This statement is not required to read a file on a multifile 
tape. 


A multifile tape is created by copying files from another storage medium to output 
files on the tape. The tape must already be prepped and it may or may not already 
contain some files. The files must be copied in sequence as they are to be arranged on 
the tape. These files cannot be extended later. 


The librarian job, which copies the files to the tape, must contain the // PARAM 
statement. Also, the // LBL job control statement for each new tape file must include a 
file sequence number parameter (in positional parameter 4) to indicate the position of 
the output file on the tape. For example, if the tape already contains two files, the // 
LBL statement for the first new tape file must specify a 3 for the file sequence 
number. If the tape is a newly prepped tape that does not yet contain any files, the file 
sequence number for the first new tape file must be 1. 


é As the files are being output to the tape, only one tape file can be open at a time. 

Therefore, the librarian job step should use the same logical file name (Tn) for every 
tape file but redefine that logical file name each time a new file is to be processed. (See 
the FIL librarian control statement description for more information.) 
Normally, after each file is written to the tape and then closed, the librarian would 
rewind the tape to the load point. Then it would reopen the tape and advance to the 
end of the tape again to write the next file. However, a // DD job control statement 
with a rewind parameter can be used in the device assignment set for each tape to 
eliminate unnecessary rewinding at each open and close operation. 
e The statement // DD OPRW=NORWD specifies no rewind at file open. 
e =6The statement // DD CLRW=NORWD specifies no rewind at file close. 
Specifically, the device assignment sets for the tape files should specify 
¢ CLRW=NORWD for the first tape file 
¢ OPRW=NORWD for the last tape file 


¢ Both OPRW=NORWD and CLRW=NORWD for all other files 
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The following sample job copies five files from disk to the same new tape volume: 


i 
// 
// 
Mf 
M/ 
M/ 
M/ 
Mf 
Ml 
Mf 
“/ 
/ 
“ 
Mf 
// 
M/ 
4 
Mf 
MW 
/$ 


/* 
/& 


JOB 
DVC 
DVvC 
DVC 
DvC 
pvc 
bvc 
Dvc 
LBL 
Dvc 
LBL 
BvC 
LBL 
DVC 
LBL 
bvc 
LBL 


MU 


LTFILE 


20 // LFD PRNTR 


58 
50 
58 
50 
50 
98 
TF 
92 
TF 


98 


TF 
90 
TF 
90 
TF 


// VOL 
// VOL 
// VOL 
// VOL 
// VOL 
// NOL 
ILt,e001 
// VOL 
IL2,,5.2 
// VOL 
IL3,,,.3 
// NOL 
1L4,,544 
// VOL 
IL5,,5,2 


EXEC LIBS 
PARAM TAPEFILES=MULTI 


D004 10 
D0G410 
D00410 
DG0410 
DQ0410 
$01841 
// LFD 
$01841 
// LFD 
$01841 
// LFD 
$81841 
// LFD 
$01841 
// LFD 


// UBL DISKFIL1 

// LBL DISKFIL2 

// LBL DISKFIL3 

// LBL DISKFILS 

// UBL DISKFILS 

// 0D CLRW=NORWD 
TAPE1 


// DD OPRW=NORWD, 


TAPE2 


// OD OPRW=NORWD, 


TAPES 


// OD OPRW=NORWD, 


TAPES 
// OD OPRW=NORWD 
TAPES 


FIL FQ=DISK1,F1=TAPE1 
cop F@,,,F1 
FIL F@=DISK2,F 1=TAPE2 
cop FQ,,,F1 
FIL F@=DISK3,F1=TAPE3 
cop F@,,,F1 
FIL FQ@=DISK4,F1=TAPES 
cop F@,,,F1 
FIL FO=DISK5,F1=TAPES 
cop FQ,,,F1 


// LFD DISK1 
// LFD DISK2 
// LFD DISK3 
// LFD DISK4 
// LFD DISKS 


CLRW=NORWD 


CLRW=NORWD 


CLRW=NORWD 
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Section 3 
Librarian Control Statements 


3.1. Introduction 


Librarian control statements define what the librarian is to do. They name the files 
and modules to be processed and the librarian functions to be performed. They must 
be included as embedded data within each librarian job control stream that executes 
the SAT or MIRAM librarian. (See 3.6 for sample librarian job control streams.) 


This section describes the syntax and functions for all the SAT and MIRAM librarian 
control statements in detail. These control statements are executed in the order that 
they are provided in the job control stream. Except for some related statements that 

must be used together, any order is permitted. 


For convenient reference, some canned librarian job control streams provided with 
OS/3 are described in 3.5. They should be used instead of the librarian to perform 


library maintenance on system release volumes. Appendix A summarizes more canned 
job control streams that are described in other manuals. 


3.2. Format Conventions 


The recommended coding format for librarian control statements is: 


LABEL AOPERATIONA OPERAND SEQUENCE 
function [.options] (p1]£,p2)C,p31£,p41£,p5) [seq-no] 
where: 
function 


A mnemonic that identifies the librarian operation. 
options 
A string of one or more uppercase letters that specifies the processing 
options to be used. A period, not a space, is used to separate the function 
mnemonic and the options. 
Examples 


COP .G 
COP.CN 
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The options available with each librarian control statement are listed in each 
statement description. 


p1,p2,p3,p4,p5 
A series of variable parameters that identify the files and modules to be 
processed. These parameters are positional, meaning that commas are 
required to indicate where any parameter values have been omitted within 
the statement. Trailing commas, however, should not be used except in the 
variation of the COP statement which lists the contents of an entire file 
without performing a copy operation. 


Examples 


DEL 01,S,COBOL86,D2 
COP.G D2, ,ACCTS, D3 
COM D1,,,,D2 

cop 03,S,COBOL55 
COP.D 07, 


seq-no 
A string of up to eight letters or digits specifying the sequence number for a 
module record. At least one character must be a digit. If letters are used, all 
letters must be contiguous and precede all the digits. 


All sample librarian control statements used in this guide adhere to the recommended 
format with the function mnemonic starting in column 10, the operands starting in 
column 16, and the sequence number, if used, starting in column 73. These suggested 
column positions do not have to be used. The only requirement is that the operation 
field, which consists of the function mnemonic and any options, must be preceded and 
followed by at least one space. 


3.3. SAT Librarian Control Statement Descriptions 
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This section contains detailed descriptions of the SAT librarian control statements. 
Each statement description includes the statement function, syntax description, and 
syntax examples. 


The statements are organized according to major librarian functions, such as listing 
modules or correcting modules. Related statements are described together. Some 
statements, such as the COP statement, can serve several functions, depending on the 
options and parameters used in the statement. In this situation, a separate 
description of the statement is given for each function. Any background information 
that is helpful when using a particular statement is provided in the function 
description. 


Sample job control streams for the SAT librarian in 3.6 illustrate how the various 


librarian control statements work together. Information on the job control required to 
use the SAT librarian is given in 2.6. 
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Table 3-1 contains a summary of the functions associated with each SAT librarian 
control statement. Each statement is described in detail in the section indicated: 


COM 


COP 


COR 
DEL 
ELE 


EOD 


EOG 


ESC 


FIL 
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Table 3-1. SAT Librarian Control Statement Summary 


Converts standard load modules to blocked format. 


Writes a beginning-of-group record in a file. 


Compares two source modules record by record. 


Compares two files block by block. 
Copies modules from one file to another. 
Advances the pointer past a module in a file. 


Prints a sequential file table of contents 
(see also LST). 


Prints a file directory. 

Prints module listings or punches modules. 
Begins a series of module corrections. 
Deletes modules or files. 

Copies a card module to a file. 


Ends a card module being copied (with ELE). 


Ends a series of module corrections (with COR). 


Ends a series of linkage editor control 
statements (with REPRO). 


Writes an end-of-group record in a file. 


Inserts a series of librarian control 
statements in a librarian job. 


Assigns logical file names. 





3.3.13 


3.3.18 


3.3.8 


3.3.9 


3.3.5 


3.3.16 


3.3.17 


3.3.10 


3.3.6 


3.3.4 


3.3.4 


3.3.10 


3.3.19 


3.3.18 


3.3.20 


continued 
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Table 3-1. SAT Librarian Control Statement Summary (cont.) 


LST Prints an alphabetical file table of contents 
(see also COP). 


PAC Compresses a disk or format label diskette file. 


PAGE Starts a new page on the librarian map and 
optionally adds or changes the page heading. 


REC Recycles the pointer during source module 
: corrections. 


REN Renames a module, group or record. Optionally 
changes the comment in a module header. 


Changes the sharability status of an object 
module. 


REPRO Inserts or deletes linkage editor control 
statements in an object module. 


RES Resets the pointer in a file. 





SEQ Adds sequence numbers to a source module being 
copied from cards to tape, disk, or diskette. 


Sequences or resequences a source module. 


Defines the sequence field for source module 
corrections. 


SKI Skips records during source module corrections. 





3.3.1. Assigning Logical File Names (FIL) 
Function 


A FIL librarian control statement equates each disk, tape, and diskette file name 
used in an // LFD job control statement to a logical file name. 


A logical file name represents a file device type code (D for disk or T for tape) and 
a logical file number (0 through 15). Format label diskette files must be declared 
as disk files. Data set label diskette files must be declared as tape files. 
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Up to16 files can be declared in a single FIL statement. Commas, not spaces, are 
used to separate successive declarations. Disk and tape file declarations may be 
included in the same FIL statement. 


The librarian map will list the following information for each logical file name 
declared in the FIL statement: 


e The volume serial number (from the // VOL job control statement) 
¢ The logical file descriptor (from the // LFD job control statement) 
* The file label (from the // LBL job control statement) | 


The FIL statement only assigns logical file names to files; it does not open the 
files. A file is only opened when its logical file name is used in a subsequent 
librarian control statement. Up to six files can be open at one time. If more files 
are used, only the latest six remain open. Otherwise, a file remains open until the 
job step is completed or until the logical file name is assigned to another file by 
another FIL librarian control statement in the job step. Therefore, if a librarian 
job processes many files and it is not necessary to have all the files open at one 
time, it is a good idea to reuse the logical file names in another FIL librarian 
control statement. This way, the files will be closed when they are no longer 
needed (see Example 2). 


Note: Because librarian control statements do not reference files by their actual 
names, the same set of librarian control statements can be used 
interchangeably to perform the same operations on any files. Only the 
// LBL and // LFD job control statements, and the FIL librarian control 
statements need to be changed to identify the new files. 


Format 





LABEL AOPERATIONA OPERAND 


aed in a 





Options 
None 
Keyword Parameter 
Tn=f i lename 


Equates either a tape or a data set label diskette file name with a logical file 
name of TO through T15. 
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Dn=f i lename 
Equates either a disk or format label diskette file name to a logical file name 
of DO through D15. 


The filename must match the file name used in the // LFD job control statement 
for the file, the system file name, or the job run file name $Y$RUN. 


Note: The filename may contain up to eight alphanumeric characters. The first 
must be an alphabetic character. 


Examples 





1. | // JOB DVCTEST 

// DVC 2@ = // LFD PRNTR 
// DVC 98 =// VOL OTALT // LBL TPLOAD // LFD SCRTAPE 
// DVC 91 = // VOL OTALT1 // LBL TPDUMP // LFD UPDATE 
// DVC 5@ // VOL OS3ALT // LBL DSKDMP // LFD PROCLIB 
// DVC 148 // VOL OS3DST // LBL DSTLOAD // LFD DSKTLIB 
// EXEC LIBS 
/$ 

FIL T@=SCRTAPE,T1=UPDATE 

FIL DQ=PROCLIB, T2=DSKTLIB 





The first FIL statement assigns the logical file name TO to the tape file 
SCRTAPE and the logical file name T1 to the tape file UPDATE. The second FIL 
statement assigns the logical file name D0 to the disk file PROCLIB and the 
logical file name T2 to the data set label diskette file DSKTLIB. 


1 10 16 





2. |// JOB FILTST 
// DVC 28 = // LFD PRNTR 
// OVC 5@ ) =// VOL DOGG12 // LBL MINE // LFD MY 
// OVC 5@ = // ‘VOL DO@O2@ // LBL YOUR // LFD YR 
// DVC 5@ = // VOL DO@B12 // LBL HIS // LFD HS 
// bvC 5@) = // VOL D@@02@ // LBL HERS // LFD HR 


/$ 
FIL D@=MY,D1=YR 
cop @,,,D1 
FIL D@=HS,D1=HR 
cop @,,,D1 

/* 

1k 


The first FIL statement assigns the logical file name DO to the disk file MINE 
and the logical file name D1 to the disk file YOUR. The first COP statement 
copies all modules from the file MINE to the file YOUR. 
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The second FIL statement closes the file MINE and reuses the logical file name 
DO by assigning it to the file HIS. It also closes the file YOUR and reuses the 
logical file name D1 by assigning it to the file HERS. The second COP statement 
then copies all modules from the file HIS to the file HERS. 


3.3.2. Resetting the Pointer in a File 


The RES and COP librarian control statements can move the pointer in a file to 
determine which modules will be processed by a librarian control statement. Refer to 
2.6.10 for a general description of the pointer operation. 


Resetting the Pointer to the Start of a File or Module (RES) 

Function 
The RES librarian control statement repositions the pointer to the beginning of 
the file or to a particular module or group. If the module or group is not found, the 
pointer position remains the same and a diagnostic message is printed on the 


librarian map. 


Format 







LABEL AOPERATIONA OPERAND 


all 


unused RES[ options] [name] 





zreon 


Options 


G- The name parameter is a group name. Reset pointer to the first group 
encountered with the specified name. 


Positional Parameter 1 


lfn 
Specifies the logical file name of the file in which the pointer is to be reset. 


If omitted, the job run file $Y$RUN is used. 
Positional Parameter 2 
$,M,0,L 


Specifies the module type as either program source (S), macro/jproc source 
(M), object (O), or load (L). 
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If used, a name parameter is also required to specify a particular module name. If e 
omitted, the pointer is reset to the beginning of the file specified in the lfn 
parameter. The type parameter is not valid when the G option is used. 


Positional Parameter 3 
name 
Specifies the name of the module or module group (with G option) to which 
the pointer is to be reset. 
When a module name is used, a type parameter is also required; otherwise the 
pointer is reset to the beginning of the file specified by the lfn parameter. When a 
group name is used, the G option must also be used and the type parameter must 
be omitted. 
Examples 


1 18 16 





1 

2. RES 03,0, EXAMPLE2 
3. RES 11,S,EXAMPLE3 
4 RES ,L, EXAMPLE 

5 RES.G D5,,GROUPS 





1. Resets the pointer to the beginning of file D1. 
2. Resets the pointer in file D3 to the object module named EXAMPLE2. 
3. Resets the pointer in tape file T1 to the source module named EXAMPLES. 


4. Resets the pointer in the job run file $Y$RUN to the load module 
EXAMPLE4. 


5. Resets the pointer in file D5 to the module group named GROUPS. 


Resetting the Pointer Past a Module (COP) 


Function 


The COP librarian control statement can reset the pointer past a module without 
performing any copy operation. It resets the pointer to the module following the 
module specified in the COP statement and prints that module’s header 
information on the librarian map. If the module is not found, a diagnostic 
message is printed on the librarian map and the pointer position remains the 
same. 


Note: Other versions of the COP statement are available to copy modules (3.3.5), 
print a file table of contents (3.3.16), and list or punch modules (3.3.17). 
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Format 









AOPERATIONA OPERAND 





LABEL 


unused 


Options 
None 
Positional Parameter 1 


(fn 
Specifies the logical file name of the file in which the pointer is to be reset. 


If omitted, the job run file $Y$RUN is used. 
Positional Parameter 2 
$,M,0,L 
Specifies the module type as either program source (S), macro/jproc source 


(M), object (O), or load (L). 


name 
Specifies a module name. The pointer is advanced past this module. 


Examples 
1 10 16 
1. COP D1,S,EXAMPLE1 
2. cop 0, EXAMPLE2 


1. Resets the pointer in file Di to the module following the source module 
named EXAMPLE1. 


2. Resets the pointer in the job run file $Y$RUN to the module following the 
- object module named EXAMPLE2. 
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3.3.3. Controlling Page Advancement for the Librarian Map (PAGE) 
| Function 


The PAGE librarian control statement starts a new page on the librarian map. It 
may also specify a header line to be printed at the top of each new page. This 
header line remains in effect for the duration of the librarian job step or until it is 
changed by another PAGE control statement. 


Format 

LABEL | AOPERATIONA OPERAND 

unused PAGE ('header-line'} 
Options 

None 


Positional Parameter 1 


‘header-line! 
Specifies the header line to be printed at the top of each succeeding page. It 
can contain up to 64 characters and must be enclosed in single quotation 


marks. @ 


This header line remains in effect for the duration of the job or until it is changed. 
If omitted, the current header line, if any, remains in effect. 





Examples 
1 1@00 16 
1. PAGE 
2. PAGE ‘PAYROLL MODULES (CONTINUED)! 
3. PAGE ' ! 


1. Starts a new page on the librarian map, printing the current header line, if 
any, at the top of that page. 


2. Starts a new page on the librarian map, using the new header line 
PAYROLL MODULES (CONTINUED) on that page and each succeeding 
page. 


3. Starts a new page on the librarian map and ends the use of any previously 
specified header. 
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e 3.3.4. Adding Modules from Cards to a Disk, Tape, or Diskette File 


A program module punched on cards can be copied to a file using the librarian. The 
ELE and EOD librarian control statements identify the beginning and end of the 
module. When a program source or macro/jproc source module is being copied, a SEQ 
statement can be used following the ELE statement to sequence the records in the 
module after they are copied. 


Delimiter Cards (ELE and EOD) 
Function 


The ELE and EOD librarian control statements delimit a card module to be 
copied to a file. For disk or format label diskette files, if the file already contains 
a module with the same name and type, the old module is deleted and the new 
module is added to the end of the file. This effectively updates the module. In a 
tape or data set label diskette file, the module is always added to the end of the 
file; any old version is never deleted. 


The librarian uses the information in the ELE statement to construct the module 
header record. This statement identifies the file where the module is being 
copied, the module name, the module type, and an optional comment. 


A complete librarian job control stream may be stored as a source module. It must 

© include all the cards required in the job from the // JOB card to the /& end-of-job 
card. Each EOD statement in the card module being stored should have a 
corresponding COR or ELE statement. The first EOD statement that is not 
associated with an ELE statement is treated as the end of the module being 
stored, unless the E option is used in the ELE statement. 


Format 











LABEL SOPERATIONA OPERAND 






ELE[ .options] S$ } ,name{, comment] 
M 
0 
L 
LABEL AOPERATIONA OPERAND 
unused EOD unused 
Options 


D- Print a listing of the module on the librarian map. 


E- Terminate the module at the first EOD librarian control statement. 
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N- Do not list the module header information on the librarian map. 
P- Punch a copy of the module being copied. 
Positional Parameter 1 


lfn 
Specifies the logical file name of the file to which the module is being copied. 


If omitted, the job run file $Y$RUN is assumed. 
Positional Parameter 2 
S,M,0,L 
Specifies the type of module being added as either program source (S), 
macro/jproc source (M), object (O), or load (L). 


Positional Parameter 3 


name 


Specifies the name to be given to the module after it is copied to the file. 
For source modules, this may be the same as the name used for the card module 
or a new name. For object or load modules, it must be the same name used for the 
card module. 


Positional Parameter 4 


comment 


Specifies up to 30 characters to be included in the module header record. 
If omitted, no comment is included in the module header record. 
Example 1 


1 18 16 





ELE 0D1,S,EXAMPLE1,REVISED 6/13/88 


. Source module card deck 
EOD 


Copies a source module on cards to the end of the disk file D1, giving it the name 
EXAMPLE1. The module header record includes the comment REVISED 6/13/88. 
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ELE ,L, EXAMPLE2 


Load module card deck 
EOD 


Copies the load module on cards to the end of the job run file $Y$RUN, giving it 


the name EXAMPLE2. 
Example 3 
1 18 16 





ELE D2,S,L18J08 
// JOB LIBJOB 


| Complete librarian job control stream to be stored 
. ) 
ik: 
EOD 
Adds the complete librarian job control stream contained on cards to the end of 


file D2, giving it the name LIBJOB. (See 3.6.4 for a complete sample job control 
stream.) 


Sequencing a Card Module Being Copied (SEQ) 
Function 


The SEQ librarian control statement can be used with the ELE control 
statement to add, check, or change sequence numbers in a module as it is 
being added to a file. This feature is available for program source and 
macro/jproc source modules only. 


The SEQ statement must be placed immediately after the ELE statement 
and before the first card in the module being copied. 


Note: Other variations of the SEQ statement are used to sequence or 


resequence a module without performing any other operation (3.3.7) 
or to sequence a module as it is being corrected (3.3.11). 
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Format 





LABEL AOPERATIONA OPERAND 








.}| tn} | ts}] 


“WI | 


Options 
~ None 
Positional Parameter 1 
tfn 
Identifies the file containing the module to be resequenced. This must match 
the lfn used in the preceding ELE librarian control statement. 


Positional Parameter 2 @ 





S,M 
Identifies the type of module being sequenced as either program source (S) 
or macro/jproc source (M). 


Positional Parameter 3 


name 
Specifies the name of the module being sequenced. 


If used, it must match the module name used in the preceding ELE librarian 
control statement. If omitted, the librarian will only verify existing sequence 
numbers in the module. 
Positional Parameter 4 
column 
Specifies the starting column for the sequence number in each module 


record. If omitted, column 73 is assumed. The length of the content | 
parameter determines the length of the sequence number field. 
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Positional Parameter 5 


content 
Specifies the sequence number to be used for the first record in the module. 
This string can be from one to eight characters long. The length of this string 
determines the maximum length for any sequence number in the module. It 
may contain letters, digits, or both. If any letters are used, all the letters 
must be contiguous and precede any digits. For example, MA400, GRP000, 
and 10000001 are valid sequence numbers. However, M4A00, 600MAST, and 
22AAA33 are not valid. 


SAME 
Specifies that the same sequence number is to be used for the first record in 
the module. 


00000000 
Eight zeros is the default sequence number for the first record in the module. 


If this parameter is omitted, the sequence number for the first record is 00000000 
(eight zeros). 


Positional Parameter 6 
increment 
Specifies decimal number from 0 to 255, to be used as an increment for 


sequencing successive records. If omitted, an increment of 1 is used. 


Example 1 





ELE 01,S,EXAMPLE1 
SEQ D1,S,EXAMPLE1, ,EXAQ@000, 18 


Source module card deck 
EOD 
Copies the source module named EXAMPLE1 to file D1 and sequences (or 


resequences) the records using columns 73 through 80. The sequence number for 
the first record is EXA00000 and the increment is 10. 
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ELE D2,S,EXAMPLE2 
SEQ 02,S,EXAMPLE2, 1,EXAQ@0@1 


Source module card deck 
EOD 
Copies the source module named EXAMPLE? to file D2 and sequences (or 
resequences) the records using columns 1 through 8. The sequence number for the 
first record is EXA00001, and the increment is 1 (the default). 
Example 3 


1 18 16 





ELE 03,S,EXAMPLE3 
SEQ D3,S,,,EXAQ080,1 


Source module card deck 


EOD 





Copies the source module named EXAMPLES to file D3 and checks its sequence 
numbers. The numbers should begin in column 73 and be seven characters long 
like EXA0000. The sequence number of the first record should be EXA0000, and 
the increment should be 1. 


3.3.5. Copying Modules and Files (COP) 
Function 


The COP librarian control statement copies modules from one file to another. 
These files need not be stored on the same type of storage medium. Modules are 
obtained from an input file and are copied to the end of an output file. Therefore, 
after a module is copied, both files will contain a copy of the module. Also, any 
modules contained in the output file before the copy operation will still be there. 


The options and parameters used in the COP statement determine which 
modules are copied. Options can also cause the copied modules to be listed on the 
librarian map or punched on cards. 


When an entire disk or format label diskette file is copied, any deleted modules in 
the input file are not copied to the output file. , 
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If the output file is a disk or format label diskette file that already contains a 
module of the same name and type as the one being copied, the one already in the 
output file is deleted and a new one is copied from the input file. 


If the output file is a tape or data set label diskette, all the modules specified in 
the COP statement are copied to the end of the file, even if the file already 
contains any modules with the same name and type as any of those being copied. 
See 2.6.7 for a description of how the librarian accesses these duplicate modules 
in tape files. 


Notes: 

1. When modules are being copied to a new tape file, the tape must first be 
prepped to initialize the new file. Otherwise, the copied modules will be placed 
at the end of an existing file on the tape. Also, the input and output files must 
be in separate tape volumes. 

2. AnICAM symbiont should not be copied to a file that contains an active 
ICAM symbiont with the same name. This would cause the active ICAM 
symbiont to be deleted. 

3.  Single-device, multivolume tape files cannot be copied to diskette. 


4. Other variations of the COP statement are used to perform the following 
operations (see the section indicated for more information): 


© Print header information for modules in a file (see 3.3.16). 
¢ = Print listings of modules or punch copies of modules (see 3.3.17). 


¢ = Reset the pointer in a file (see 3.3.2). 


5. The SETREL and COPYREL canned job control streams are provided in the 
system to back up and copy the contents of the system release volume. See 
Appendix A. 


Format 






LABEL AOPERATIONA OPERAND 





unused COP[ .options] [,name],output-t fn , VERASG=n/n/n] 





rozn 


Options 


A- Copy all groups with the group name specified in the name parameter. (The 
G option must also be used.) 
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C- Copy all modules from the pointer position in the input file to the end of the 
input file whose names begin with the prefix specified in the name 
parameter. If both a name and type parameter are used, copy all modules of 
that type with that name prefix. If the G option is also used, copy all module 
groups with the group name prefix specified by the name parameter. 


D- Print a listing of each module copied. 

G- Ifthe C option is not used, the name parameter specifies a complete group 
name. Copy the next group with that name. If the A option is also used, copy 
all groups with that group name from the pointer position to the end of the 
input file. 

If the C option is used, the name parameter specifies a group name prefix. 
Copy every group with that name prefix from the pointer position to the end 
of the input file. 


M - Perform updates only. Only copy a module from the input file if it has the 
same name and type as a module already in the output file. 


N- Do not list header records on the librarian map. 


P- Punch the modules copied. 





Q- Add new modules only. Only copy a module from the input file if it does not 
have the same name and type as a module already in the output file. 


U- Only copy modules from the pointer position in the input file up to and 
including the module specified by the name and type parameters. If the G 
option is also used, copy all modules from the pointer position up to and 
including the next group with the name specified in the name parameter. 

Note: Anerror occurs if the C and U options are used together. 


Positional Parameter 1 


input-lfn 
Specifies the logical file name of the input file. 


If omitted, the job run file $Y$RUN is used. 
Positional Parameter 2 
S,M,0,L 
Specifies the type of module being copied as either program source (S), 
macro/jproc source (M), object (O), or load (L). 
If omitted, all modules with the specified name are copied. If both name and type 


parameters are omitted, all modules from the pointer position to the end of the 
input file are copied. The type parameter is not valid when the G option is used. 
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Positional Parameter 3 


name 


Specifies the module name, module group name (with G option), module 
name prefix (with C option) or module group name prefix (with C and G 
options) for the modules to be copied. 


This parameter is optional, unless the C or G option is specified. If omitted, 
all modules of the specified type from the pointer position to the end of the 
input file are copied. If both the name and type parameters are omitted, all 
modules from the pointer position to the end of the input file are copied. 


Positional Parameter 4 


output-l fn 


Specifies the logical file name of the file to which the modules are to be 
copied. 


Keyword Parameter 


Examples 
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VERASG=n/n/n 


1 


Specifies the version number to be applied to the module being copied. 
(Should be specified as last parameter when used with positional 
parameters.) 


18 16 





SS WN m= 
es ee « 


COP.D D1,S,MYMOD, D2 
COP.UN DO,M,MYMOD, T3 
COP.C T4,L,MY,D5, VERASG=6 
RES D6 

COP.C D6,S,COB,D7 

COP.Q D8,,,D9 

COP D10,0,,011 


Copies the source module MYMOD from file D1 to file D2 and prints a listing 
of the module MYMOD. 


Obtains all modules from the pointer position in file DO up to and including 
the procedure module MYMOD and copies them to file T3. The module 
header information for these modules is not printed on the librarian map. 


Finds all load modules whose names begin with MY from the pointer 
position to the end of file T4 and copies them to file D5. Assigns version 
number 6 to each module copied. 


Resets the pointer to the beginning of file D6. Finds all source modules with 
the name prefix COB in file D6 and copies them to file D7. 
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5. Finds all modules from the current position in file D8 to the end of file D8 
that do not exist in file D9 and copies them to the end of file D9. 


6. Finds all object modules from the pointer position in file D10 to the end of 

file D10 and copies them to the end of file D11. 
3.3.6. Deleting Modules and Files (DEL) 
Function 

The DEL librarian control statement logically deletes modules from a disk or 

format label diskette file. Deleted modules cannot be accessed, but they still 

occupy space in the file until the file is compressed by a PAC operation (see 

3.3.15) or a COP operation that copies an entire file (see 3.3.5). 

When the DEL statement is used to delete a load module, only the header record 

for the root phase is printed on the librarian map, even though all overlay phases 

are also always deleted. 

Notes: 

1. AnICAM symbiont should not be deleted while it is actively processing. 

2. The DEL statement cannot be used to delete modules from a tape or a data set 
label diskette file. The only way to eliminate unwanted modules in a tape file 
is to make a new tape, copying only the modules to be kept to the new tape file. 


Format 







LABEL AOPERATIONA OPERAND 


unused DEL[ .options} 


{S$} ]t.name] - 
0 
M 
L 


Options 


A- Delete all groups with the group name specified by the name parameter. 
(The G option must also be used.) 


C- Delete all modules from the current position to the end of the file whose 
names begin with the prefix specified by the name parameter. If the G option 
is also used, delete all groups whose names begin with the prefix specified by 
the name parameter. : 
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G- The name specified in the name parameter is a group name or group name 
prefix. If the C option is not used, the name parameter is a complete group 
name. Delete all modules in the next group with that group name. If the A 
option is also used, delete all groups with that group name. 


If the C option is used, the name parameter specifies a group name prefix. 
Delete all module groups with that name prefix from the pointer position to 
the end of the file. 


N- Do not list module header records on the librarian map. 


U- Delete all modules from the pointer position up to and including the module 
with the specified name and type. If the module name and type parameters 
are omitted, delete all modules from the pointer position to the end of the 
file. If the G option is also used, delete all modules from the pointer position 
up to and including the specified group. 


Note: An error occurs if the C and U options are used together. 
Positional Parameter 1 
lfn 
Specifies the logical file name of the disk or format label diskette file 
containing the modules to be deleted. 
If omitted, the job run file $Y$RUN is assumed. 
Positional Parameter 2 
$,M,0,L 
Specifies the type of modules to be deleted as either program source (S), 
macro/jproc source (M), object (O), or load (L). 
If omitted, all modules with the specified name are deleted. If both the name and 
type parameters are omitted, all modules in the file are deleted. The type 
parameter is not valid when the G option is used. 
Positional Parameter 3 
name 
Specifies the module name, module group name (with the G option), module 
name prefix (with the C option), or the group name prefix (with the C and G 
options) for the modules to be deleted. 
If omitted, all modules of the specified type are deleted. If both the name and 


type parameters are omitted, all modules in the file are deleted. The name 
parameter is required when the C or G options are used. 
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1 18 16 





DEL.D 01,S,EXAMPLE1 


1 

2. DEL.P ,0 

3. DEL.C D2,0,EXA 

4 DEL.UN D@,L,MYMOD 

1. Deletes and prints a listing of the source module EXAMPLE1 in file D1. 


2. Deletes and punches all object modules in the job run file from the current 
position to the end of the file. 


3. Deletes all object modules from the current position to the end of file D2 
whose names begin with the letters EXA. 


4. Deletes all modules from the current position in file DO up to and including 
the load module MYMOD. Does not print the module header information for 
these modules on the librarian map. 


3.3.7. Sequencing and Resequencing Source Modules (SEQ) 


Function 





The SEQ librarian control statement sequences or resequences records in a 
program source or a macro/jproc source module. It cannot be used for object or 
load modules. If the module does not contain sequence numbers, they are added 
as specified by the parameters and options in the SEQ statement. If the module 
already contains sequence numbers they are changed as specified. 


Note: Other variations of the SEQ statement are used in conjunction with the 
ELE (see 3.3.4) and the COR (see 3.3.10) librarian control statements. 


Format 





LABEL AOPERATIONA 







OPERAND 


tna hf a se | 


Bag0d000 
, | increment 









unused SEQ[ options] 
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Options 


D- Print a listing of the module on the librarian map after the module is 
sequenced or resequenced. 


N- Do not list the module header information on the librarian map. 
P- Punch the module after it is sequenced or resequenced. 
Positional Parameter 1 


lfn 
Specifies the name of the file containing the module to be sequenced. 


If omitted, the jb run file $Y¥$RUN is assumed. 
Positional Parameter 2 


S,M 
Specifies the type of module being resequenced as either program source (S) 
or macro/jproc source (M). 


Positional Parameter 3 


name 
Specifies the name of the module to be sequenced or resequenced. 


Positional Parameter 4 


column 
Specifies the starting column position for the sequence number in each 
module record. 


If omitted, column 73 is used. 
Positional Parameter 5 


content 
Specifies the sequence number to be assigned to the first record in the 
module. It can be from one to eight characters long. The number of 
characters used determines the maximum length for any sequence number 
in the module. It may contain letters, digits, or both. If any letters are used, 
all letters must be contiguous and precede any digits. For example, MA400 
and GRP000 are valid. However, M4A00 and 600MAST are not. 


SAME 
Specifies that the sequence number for the first record in the module is to 
remain the same. This is used only if the module is being resequenced. 


If this parameter is omitted, the number 00000000 (eight zeros) is used for the 
sequence number of the first record. 
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Positional Parameter 6 


increment 
Specifies the increment to be used to sequence successive records. It can be 
any decimal number from 0 to 255. 


If omitted, the value 1 is used for the increment. | 
Examples 


1 18 16 


1. SEQ.DP D14,S, EXAMPLE 1, 20, LNK@QQ, 18 
2. SEQ.N 012,S,EXAMPLE2, , SAME 


1. Sequences the source module named EXAMPLE1 in file D14. Sequence 
numbers are placed in columns 20 through 25. The sequence number for the 
first record is LNK000 and the increment is 10. The sequenced module is 
listed and punched. 


2. Resequences the source module EXAMPLE2 in file D12, using the same 
sequence number for the first record and an increment of 1 (the default). 
Each sequence number is in columns 73 through 80 (the default). The 
module header information is not printed on the librarian map. 





3.3.8. Comparing Source Modules (COM) 
Function 


The COM librarian control statement can compare two program source or 
macro/jproc source modules record by record. 


The two source modules must be in separate files and have the same name and 
type. They must also use the same column positions for the sequence number 
field. The SEQ librarian control statement (see 3.3.7) may be used to reposition 
the sequence numbers before the compare operation is done. 


To perform a compare operation, the librarian first locates the modules in the two 
files and then starts comparing them record by record. When it finds a difference 
between corresponding records, it lists the two records on the librarian map. It 
then compares the sequence numbers of those two records. If one sequence 
number is lower, the librarian advances to the next record in that module. If the 
two sequence numbers are equal, it advances to the next record in both modules. 
Then it compares the new pair of records. When the librarian reaches the end of 
one module, it prints any remaining records in the other module. 
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Figure 3-1 illustrates part of a librarian map for a module compare operation. It 
contains the COM statement followed by the two module header records, one 
below the other. Next is the heading SOURCE RECORDS THAT ARE NOT 
EQUAL. Below that is each pair of different records, one below the other. 


The first record in each pair belongs to the module whose header record is listed 
first. The second record belongs to the module whose header record is listed 
second. If one module ends before the other, an END PRIME MODULE or END 
OF SECONDARY MODULE message is printed followed by the remaining 
records in the other module. 


Note: The COM statement used to compare two complete files is described in 
3.3.9. 


Format 





LABEL AOPERATIONA 











prim-lfn) |, {i rfn-n ;name, sec-\ fn 
iN M 73-88 
Options 
None 
Positional Parameter 1 
prim-lfn 
Specifies the logical file name of the file containing the first module being 
compared. 


If omitted, the job run file $Y$RUN is assumed. 
Positional Parameter 2 


S,M 
Specifies the type for both modules being compared as either program source 
(S) or macro/jproc source (M). 


Both modules must be the same type. This parameter is required when 
comparing two modules. If omitted, the two files specified by the prim-lfn and 
sec-lfn are compared as described in 3.3.9. 
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Positional Parameter 3 
acn 


These two integers separated by a hyphen specify the column range used for 
sequence numbers in the records of the two source modules being compared. 


Both modules must have sequence numbers in these columns. If omitted, the 
column range 73 through 80 is assumed. 


Positional Parameter 4 


name 


Specifies the name of both modules being compared. 
Both modules must have the same name. This parameter is required when 
comparing two modules. If omitted, the two files specified by the prim-lfn and 
sec-lfn are compared as described in 3.3.9. 


Positional Parameter 5 








sec-lfn 
Specifies the logical file name of the file containing the second module being 
compared. 
Examples 
1 1016 
1, COM D1,S,,EXAMPLE1,D2 
2. COM 03,S, 1-8, EXAMPLE2,D4 
3. COM, S, ,EXAMPLE3, DS 


1. Compares the source module named EXAMPLE1 in file D1 with the source 
module named EXAMPLE1 in file D2. The sequence numbers are in columns 
73 through 80 (the default) of each source module record. 


2. Compares the source module named EXAMPLE? in file D3 with the source 
module named EXAMPLE? in file D4. The sequence numbers are in columns 
1 through 8 of each source module record. 


3. Compares the source module named EXAMPLES3 in the $Y$RUN file with 
the source module named EXAMPLES in file D5. The sequence numbers are 
in columns 73 through 80 (the default). 
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UNISYS OS/3 LIBRARIAN REVISION 
CONTROL ComMAND OpEKAND 





FIL pimyCShLIB2 OZ2eJCSLIB2Z,D3aJCSLIGB3 ,DYPUCSLIBY 


COM =z yeh SBSFOReDY 


SOURCE HEADER Wane DaTE Time COMMENTS 
LIBSFOR 092274 b4aiz 
Lyesror 042274 2240 


SOURCE RECOROS THAT ARE NOT EQual 


LA riie) 
avi L8sCOm,x°00° 


LesComAy Myvi LBSSWITE Ak" 908 
avi LOSCPRINT 


cul OtR7),ceT?® 
USING R456 


e END OF SynTax CHECK 
USING R4,5e6 


STH R5,L8sCONSI¢4 
MVI 


LesAgurr OC AULBSymeurFe36) 
Swtco E@U 


END OF PRIME MODULE 


OO Sh 


PUT OnE INTO REGISTER 


RUNLIo NO TYPE CHECK 


IF EQe yAPE ERROR 


DISPLACEMENT INTO CODING 
LOSCPRINT,X°90 


Figure 3-1. Sample Librarian Map for a Source Module Compare Operation 
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3.3.9. Comparing Files (COM) 


Function : 


The COM librarian control statement can compare two library files containing 
any assortment of modules. 


The librarian compares two files block by block in their entirety. When it finds a 
difference, it lists the two blocks in hexadecimal format side by side on the 
librarian map. It then advances each file pointer one block and does the next 
comparison. It continues this process until it reaches the end of one file. It then 
lists any remaining blocks in the other file on the librarian map. Figure 3-2 
illustrates part of the librarian map for a file comparison operation. The block-by- 
block listing begins immediately below the COM statement. 


Notes: 


1. Two files containing the same modules may not always compare exactly. To 
ensure a correct comparison, both files should first be compressed, or packed, 
using the PAC librarian control statement (see 3.3.15). This is especially true 
for files assembled and managed using a librarian from Release Level 7 or 
earlier. When the librarian from Release Level 8 forward is used, the packed 
and unpacked versions of two files containing the same nondeleted modules in 
the same sequence will match. 








2. The COM statement can also be used to compare two source modules record by 6 
record as described in 3.3.8. 
Format 
LABEL | AOPERATIONA OPERAND 







unused 


i a 





Options 
None 
Positional Parameter 1 


prim-lfn 


Specifies the logical file name of the first file being compared. 


If omitted, the job run file $Y$RUN is assumed. 
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Positional Parameters 2 through 4 


These three parameters should not be used when comparing two files. The four 
comma separators, however, are required between the prim-lfn and sec-lfn 
parameters. If a module name is included as positional parameter 4, the librarian 
also expects values for positional parameters 2 and 3 to do a module comparison 
as described in 3.3.8. If a module name is not included, any values in parameter 
positions 2 and 3 are ignored. 


Positional Parameter 5 


sec-lfn 


Specifies the logical file name for the second file being compared. 


Examples 
1 18 16 
1. COM D1,,,,D2 
2. COM ,,,,D3 


1. Compares files D1 and D2 block by block. 
2. Compares the $Y$RUN file and file D3 block by block. 


Figure 3-2 illustrates the beginning and end of the librarian map for a block-by-block 
comparison of two files. 
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BLOCK REC NAME TYPE OaATE TIME 
PRIME FILE BLOCK NO. O0O0U01 BLOCK LENGTH FT? 


goocoif? ouo7clc3 D2cscs03 u7A40000 929501C3 E207C1C3 
O240A40G OO0SaFO7 O2C8C503 O7FOFO90 acuad758 E3CSE2ZE3 
C3E2FOFO 30000008 40D3C9E2 £3C89740 40A4090G OCISCIE2 
D4O7D9C7 4040A4CO ANOSI6C7? CS5SE3D4U3 C9C24080 8 UIONOF TE 
C7CSE304% D3C9C240 O870300F 4793C9C2 CaC40940 40040000 
OFCCD3C9 C2ZE3E7TE3 40469400 uvaIFDOD? oO9c6c903 C€5404094 
JOQOOFCE D9C9CZE3 ETEZHO4O JeaunIaId A5u9C9C2 Cs8C4D94D 
40040090 10160709 C9C24949 4N4d04U0 = 9N192703 CIE2ZESCI 
C50307a4 GgoudiscsS C7CS£304 Y3C9C240 AYOQUOOIA 8709C4C3 
CS03D77G FO90ITGO 2305°58C5 O39707CL C3D2A400 JO3015C3 
Clv90Nel C9U5SE3AH = 00900318F yOn9I9NNC 


PRIFE TILE BLOCK NO. 390992 SLOCK LENGTH FT? 


QNQ002F7 Duc3C4HC3 OBOTEAFU FUYNIWGIA 3322C3C1 NIO4NSES 
FOFQ9900 UO5341C1 CHCSC593 S7IFIFI9N 390993915 CIC4CHCcEe 
C503D740 A4¥U00993 BHE2SSE2 07V9N6C2 CSA4O9NII 9SB1E2C6 
C3ESCSC2 E3S4HDA4CO VOPSALE2 CSCIDICS E2HO4NAH UDONSASES 
f2coC3C3 E2cSFUFS 9900509R 60e2C6C3 O9E4O0S4D0 40A49019 
PECSC4HCH VHUTE2ZCS V9I5UNDD ABAAIMMCH EHONDTE?] C3FOFIIA 
uOUOALAD D709E2C3 DIDEFUFA FIUTIIAD AKYC25999 FAIFQ4I4D 
SJAYOOSO AF39CK5B) DOFIFI4YI 4I4DA4UD GIS271C3 = SANVFNF2 
40404684 OUJ0d376 C3S5FO9FN FOFTENGY = A4j90PSS 4OC3SKDO 
FOFOFLSO 4OA4UCO0 66740353 DIFUFIF2 40478402 008732C4% 
SBO9FOTO F4a4decAy 89093895) 20399000 


PRIME FILE BLOCK VO3w. GUID? SLICK LENGTH 34 


QO00U324 uvocdssd09 FOFSFS4O 4:44 109 493709855 OOF IFES 
4O40A4I0 UOSAB2C8 SROSFIFO FTYN4IAY 2UIIBCIS C5CSC4U3 
C9C24040 AlYOUDBC THE2ZE3K€2 V7V9INOCZ CS5SA4GDIN 9SB1E2CH 
CSESCST2] E340A400 DOVHALE2 COCIDIC3 CA4D4TAH YOCIVAZE 
E2c6C3c3 E2E3F OFF 9OUNGI9Y 43F206C3 09649549 4NA4¥Qnng 
SECSC4TH D4D7TEZC3 CIDSAHIO YTAI7TICH EeD4UTE2 C3FQFNII 
QAQUALAD UTUXE2CI OINSFOFG 9IITDDAD AYCASHIO FIFV4040 
49AHOUD0 AF S9CASS DOFOF Lad gO4dAGIN 99527103 SA259FUF? 
HO404ER4 YOUUSSTS CBS5H99F) FUFL4O4G = AGOIVISZS 40NC85309 
FOFUFL4U 4OA4O0OCD 3O7TACI54 DIFOFNF2 4740A499 JO8732C5 
OSC4O3SC9 C24Hu4TAl YAANS7TIO IIIA 


PRIME TILE BLOCK NO. YOANN BLUCK LENGTH ZF 


OQOvGOILE 3OS$8A4CO ADUTGIUO AINMNICGI AV9ITDGDT €1C302C3 
C5030751 04276914 52404940 40454040 40404040 40404049 
40404060 49404049 49404040 41474010 2407C1C3 D208C5D3 
O74HO0E2T3 CID9E34O FOOC2SNF 99C?2C103 cCO4O4NFl F268FUUC 
250909C4 E2C9USCT 4OSCOKFL F290250A YV9D7TD9CI VSE34005 
06C7CS505 17251409 dD607CSUS 4949D35C9 C2E3E7E3 684009C9 
C2ESE7TC3 SO172514 JIDEDICS 05434003 CIC2C8C4 09634009 





PAGE # NON2 
COMMENTS 


SECOND FILE BLOCK NO. ananot ALOCK LENGTH FT? 


QOGOOLF7 GOD406C4& C4F1494F = 4NALONAN 91050806 Cac4aF24ao 
4O40A400 09043404 OSCHCHF3 40904048 ONONNSSS DO8DECHCS 
F4404N40 A¥QG00097 SN4DS6C4H CHeFS4O4H 3 4Naannon Ofu50406 
C4CHF640D 4940A4809 ANORAANG NSCSCIFL 4NeNaNAs 9000976 
D4DEeC4Cl F2404049 AKONNANF LFNKNNSee CIF SENFQ 6FC900000 
OFY3D4D6 CHCIF4FO FOFNIAND 19134NDe OSC4HCIFS #O4O4OAS 
QV001L4IS vedsCHCl FRENANHH AYNNHNIS 960406C4H CIF 74040 
4N80U000 IT7ECTCS EBO4NIC®9 C24NHNANN HNITRINY CIC2CS8C4 
09404004 QGOUL7TCC NIC9C2EX LFLZHHaN Oaananr7? O9507D9C6 
C9D3CS549 4dO40GO" I7EFN9C9 C2ZE3E7TE3 4NHNNKON 15189509 
C9c2cscy 99404904 9N91816 aANGAANHN 


SECONO FILE BLOCK NO. onnnin2 RLOCK LENGTH FT 


0OIVIV2F7 OID7TB9ICI CP48NeNAH 49OD4AHANN 18270495 CHC3FLeC 
4O04QA409 00206504 DALHCIF2 4N4NANAH NNAHN2222 Nwdecacs 
F3404N40 «440009023 2°7N8NSCH CIFH4HNYN HNANNNNN 2T7IEDNO6 
C4C3F5FO FOFIJGOCN 1N2A9N5N4 OSC4C IFA 8TENeNAS NCOO2815 
O¥O6C4C3 =FTFOFOFO ANNANNZL BADKD6CeH CUFRFNFN © QOOu00N0 
SHA4D4DG CHC2FI4D 4N4NAGNN AAIASING NSCHC2F2 4ONOKOAG 
099703005 D4DEC4HC2 FRFNFAFQ SNNNONSA FRANHNACH COF 44040 
43A4H30997 S315D406 C4CPFS4N 4N4UNAUHQ ANSURFNS DGC4HC2F6 
FOUFOFNIN 89095622 NYNKAC4l2 FIFHFNFN OAAAANTA §=410806C4 
C2F3FOFO FuovydG000 46150896 C4HCSFI4Q 4N4NA4ON 95368404 
OSC4HCSF2 4¥O04940A4 NNNABAKC 99990099 


SECOND FILE BLOCK NO. anannys ALACK LENGTH 68 


09303363 IJGOXDeC# CSF3494D 4OAGNNNN 89410406 C4CSFa4n 
4N4UA4I0 O06A9503 NSCICHE? 4NANENAN QINOAASA DeNEc4cs 
FOFOFNFO 20000088 627N4NKAcCy CIF7FAFH FASNANDH 3F0S04D6 
C4C3FRFY FOFO9009 OACKAAUNT NACICHF? 4NNNanAR sOncc39 
C995C493 C9IC2Z4904O ALTNANNCC 43048NKCH CRFRFOFH FOVGOOOR 
SHAGV4D6 CHC2FI4D 4O4NAGNN AHN3A390H = DACHCIF2 C404Nae 
00093005 O4D6C4C2 FUFOFAFN YONNNNYA TRDNNSCH C2F44O4O 
47A4j900 $3150406 C4L>FS4N 4NAHASNN ANSHBEDY NGCHC2F6 
FIFOFO9N gO005622 D4NACHC? FIFAFNFA SINNAN76 41D406C4 
C2F8FOFO FO900000 AFI5SND4DH CHCSFI4EO 48Nana¥od ASB6B4CS 
U5C4D3C9 C2404uA1 ANANBRAC ANANANAN 


SECOND FILE BLOCK NO. onnnnl SLACK LENGTH F% 


UDJOOIE3 QGI38A4HD0 ARAAANAAN NAAANAANHA AAANNANNS DECHC4Fl 
40494030 98081634 244ned4nQ ¥NANanan 4yAananen 4sanan4en 
40409040 40404045 8NaNenan 4HaN4N2F 24N2FNFNH #KO40D9E4 
OS4O0D709 DeC3CSE2 £2N59940 CEOSCIDS EUOSFICS NICSC4H4D 
CS090906 O949C306 C4f54905 NSDSDS3R 2539NKE1 DS4ncso9 
09060940 E6CIE2Z49 C4HCSESCS C3ESCSCH 4NCUENDO = CIDSCTHO 
C10540CS ETC30740 CHFE49SC? ESCINADS 4R4NC1O3 N34006C6 


Figure 3-2. Sample Librarian Map for a File Compare Operation (Part 1 of 3) 





$JUOW9ILIS [04305 UelIesqI] 





by A8Y THBSdN 


I€€ 


BLOCK REC NAME “TYPE DATE TIME 


c9c2cec4 09501725 14090607 C5054040 O03C9C206 E4E36840 
D9C9C206 EYE3SO0E 25010903 ClO7O04FO 687EF3C& 7OFUT7DIA 
251709C4 O4F2C503 4003C9C2 C8&C4D968 D3C9C26B C8C90568 
40F0S000 acgc0300 adaog0d0 00900003 


PRIME FILE 3LOCK NO. DOGUN2 3SLOCK LENGTH €5 


aoogg2cS 90112508 aOnoecics 050306D5 O740C5D8 £4N0035C 
19251209 C4o4cocS D74aN3C9 C2c3c4no 46sCsC4dD9 C2E4CENnd 
2501092 O40604C9 06C50997 06099C25 GIN9C2D7 USOsCSdeE 
C6C9D3CS = GE250109 D3ICIUTONY FLESC8CH COCZE4CH 19251699 
CHD4E2CS5 O034003C9 C2ETETES o68D3C9C2 68C9D563 = 4DFNSDOE 
2901090 ClU7TO4FO ofC38C409 C2E4C61A 251709CH D4E2C5D3 
4O03C9C2 DGEXE363 O3C9C265 YJ6E4YE368 4OFOSNLL 250800E3 
C5E7TE303 DeD6D74HO CS5U8E4¥9D 935C1525 1209C404 C9050749 
O3C9C2C3 ETESORES EFE3C2ZE4 C6GD02501 99C20406 O04C906CS 
090906C9 aCc2591C9 C2075504 Cic4c4oe Dec4ac253 C8C9U56% 
4oFUSOSU a00cunN0O0 unneal90G NAGSAGUA 


PRIME FILE BLOCK NO. 303943 BLOCK LENGTH FB 


OOOOUSFB GOlS2512 IASCHO4VSH EXE 34NI3 CIC206E4H Z3OPE3E7 
EIC2E4CH Gd2500C9 C2N7TI5E3 CSZ7E3L3 046060719 28960NC1 
CHC40456 C4HG2I3CS§ DAEHUIAS 3€162523 GIC4HO4HE2? CH5934203 
C9C206C4% E364b0IC9 C263CICH C4HII259N C9C79705 Y4C1C0995 
03060607 10250500 CS06C6C9 43C50233 CSNBE4¥UG 935C9C25 
G909C303 voE2C54O 5C€C10303 15253239 C536D10F 24C994CS 
O909V659 YOHNCSCl LSC3CSd3 YF25605U0 G3C9C2E3 F7E 30333 
C3c4cyvc2 ve250500 O3C9C2C8 C4HN93u3 c3CHC9IC? DE250500 
D3C9C2D6 E4e303N3 C3CHC9C2] 10280599 DYCICZES EPE3N2G3 
CSOB8E4GD O35C0£ 25 U38N9TSDS ESCIEBHS DSCICZE3 27539025 
U1O9C4C3 = YOuUsE7T7D CIFOFIFI 79039032 


PRIME FILE BLOCK NO. 679J94 SLGCK LENGTH CA 


NODVO4TA 00112501 JICHC3JA WETTOF2 F2FOF2FI FOF3CS$70 
OF250159 C4C30964 ET7TOFSFS FIFIFCFL ITAIF25%91 79040395 
OMETTOFO F2FUFIF? F77D9025 38U9CHC3 OSIHETTN CIFIFOFD 
70102595 YNo9C7C2 C8CHu9I2 URCSUALHY BISZSCNE 25Q0R99C5 


DSE3D9CB8 =4UD9ICIC2 C3IC4I9ID = 2EILI9CH C30594E7 TOCLFIF) ~ 


FOTOLI2S O1I9CHCS DANHET7O FOF2FOF2 FOFLFOFC 799F 2501 
O9C4C306 OHET7OFA FSFOFIFU FITOOF2ZE G19SC4HC3 1D804E77D 
FOF2ZFOF) FTFI7OCD 250199CK C3IOS4HET TFOCIFIFQ FO791025 
O50U09C9 C2V6E4E3 J203CS59R £439:)35C 9E259809 C505E309 
E84009C9 C2H06E4ES UN25)199 C4C3}6U4 ET7OCIFO FOFOTD2S 
Gi09C4l3 = JeuU4HE77D CIFOFUFO 70970058 


PRIME FILE BLOCK wO. JO0NUS aLOCK LENGTH FS 
goooosre 00112501 O9C4C30A NYET70F2 F2FOF2FO FOF3C370 


oo250109 c4c306ce ET7OFOC2 FOF37V11 250109C4% C3OAU4CL 
O3F 34003 C9CZE4C6 €6502125 OLO9C4C3 OAQKET7TO FOFSFOF2 


COMMENTS 


4OE3CBC5 
C3C1E3C5S 
090605C7 
Qgooo000n 


SECOND FILE 


o00002E2 
C5E2E206 
4ND3ClE2 
Ca49C995 
09090609 
D3C9C209 
C9CSC426 
O9CSC3ES 
OSDSDS57TE 
beD94NDg 
00393000 


SECONO FILE 


ONIIVIBE FS 
C4coa9cs 
04242525 
VICSE 22 
27029505 
O9E840C) 
OSOS7EFQ 
4IEACIES 
OSDN94NC1 
G9CSI5E3 
C5490508 


SECONO FILE 


190094UC 
c4cg9cr7cs 
cic7cs4a 
4n4160038 
4o9n404n 
494A0196 
4)6040E 3 
C3CSE2E2 
DSC 306E4 
4NE3C3C9 
c5400505 


SECOND FILE 


099935F1 
D9ICSESCSO 
C3CIEXE2 


PAGF # Nan3s 








34253704 C5N9D9D6 09400305 C4C5SE240 CI20SCaC9 
C440C2E8 4NNSN5D5 O54ND9CS CACSN94N E20640E6 
4OC9DSC&6 046N9D4C1 E3c90605 ANAnNNnoN NAoooONGN 
oog0e000 9NNGONNN ONoON000n 

BLOCK NO. 9nNND?2 RLOCK LENGTH E? 
30392536 A4¥CINS4Q ESCRCS4HN DPESNS4N N709D6C3 
D94NE3CL C2NCSE2 ARYNCSET? CICSOTE3 4CE3CBCS 
E341C509 99060949 C3D4CHCS 23252004 EGCBCICS 
C4C9C3C1 ESCSF7R4N CL4YNCACL N9CHEKCL NECcsancs 
TA2C2529 ABNSOSDS ASTEFAFN FNFIENSN N9E4DS40 
Cl1O9EB4D C3CIDSOS DOAEZHNL2? CKS4NEZO7 CSC3CICE 
25230805 ODSOSOSTE FOFOFRFQO 49HANIDK CT4HOCHC>D 
J6D9E349 C§9E24I71C9 OS4NCS5N9 0906N92A 25270805 
FAFOFOFN SAanceco F2024NC1 C4HCanecsS F2E240C6 
C5ClIC44Q = LOEPHNFO =8C€S§N9NKANS ANANAHAN AgQOOVONH 
gaugoo30 9ngnansn ananinana 

BLOCK NO. OANND RLOCK LENGTH FR 
OA282527 98N5SN5SNS DSTFFIFN FNFNaNYN NiDec240 
C3E306N9 FS4NCICH CHNICSE2? E24NC9EF? HIOENCSOS 
03050505 OSTFEFUFN FOFN4NHN CHC9IE?702 4SC1Cacy 
4ONC606D9 4NEKD9CO F3LSHNCI F24NFICS NIDS2A25 
DEDSTEFS FRFOFNUN HANIDACZ2 49C4C9NF CSC3IE3D6 
C4HC4D9ICS FVEPHNCD F2BNEWCS NENH2F26 20080505 
FRFJFO4? 4NC5SE7TCI NTTHMEZCH PPNHCINS CLE ICSCH 
C84NC961 = DASACSE?F CBCSITES CINHNS3H 253804C6 
D30347D6 = ESCATSNO® 4ALSNOHe HNAngancs NLEC4CSE2 
CSUC94UTF FRCSOINT 4ICSCING NSDS7FaN FECSC5DO 
o549cve2 9990NAGH ANANOASN 

BLOCK NO. SANDY SLOCK LENSTH NC 
ODG20252A AMESCACS 4NOICLE? E4NF3CR OFCSCS4O 
EZE249C6 NENANYHA FICHAC54N NOFNFNHN DNXCSE2ZE2 
33a4CG09 999097909 9n9NANAN GA9NNHDS C4C4F 240 
68163523 4nenenan ¥nenanen ananenan = 4¥c04g4o4o 
8O404nad SNananen 4N4n3ZF24 DOFNFI4YA 420106C2 
C205C104 CS4F4NNS NSESHNE? CICKCSCH E4DSCSCH 
CS509G4C9 ASCIZICS CH4HNCZ2FEA 4NDVEHDS 42970906 
D6D93125 = 2ENKCINS 4NCSHEN® NANP4HNES Cif 2kOCS 
DSESCSN9 CSCHHNET CACLET4N N9ICSHNSCH CSO9CSCAa 
E2400106 f2CS5NIN7 4ACSCINS ONSNSTF4N ESCACSOD 
o9549cve2 AnAAAaAnA ANnaNnAnaANA 

BLOCK NO. Onnans RLOCK LENGTH FI 
003C2539 O4E4DSCS5 EPCSCIEH FSICICIN S4B84007 
DOESE203 ER4YNN3CE EZETCSCH 4NCSN9D9 DLO9E240 
CSC440E3 £599N4C9 NSCLE3CS 060549838 A4xgnonoa 
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w 
| Ww a a CO ee I A rR C 
nm PAGE # nnS7 

BLOCK REC NAME TYPE DATE TIME COMMENTS 
02920010 O30AEFIO 2FNA1907 ANNAIL2ZN 170N2Z5HN NAdanaiFO 
OA854680 C1CCO253 C?RFCARF SS1NCA6H SAANCARTE 92201002 
92001003 OAEFIO2F NAL9070N NALCARIZ2 ANBNNINN O902140A 
B8547FOCO 4018000A 174970958 INC22H47 FNC?2A5SC C103030A 

| 270A1A11 2C0000D7 O8PSEIN9 = 4NeH4anon aNoANnoN Asanonoo 
00000000 an0c00000 anANnnNoN ANGHAnnNnH AnNnHnnn AdN000011 
2COOONE2 C309C6C9 A*snanon ANANNADN OANNANnN Nsoo0cco 
guag0c00 ag0000009 annnoanan aAnnonrnn NOONANAN NnoOOsN20n 
7A0K89300 O2COA100 WNL77COHL RENARSNH? 

PRIME FILE BLOCK NO. GOGOBC BLOCK LENGTH 385 SECOND FILE BLOCK NO. ANGNCS RLOCK LENGTH "A 
GOJOCRFA QOO0E1200 A4NNHNAH N298ANNH ABNINZAY 991F1200 
14039030 O2aACA000 69910979 13590886 710109278 33008001 
Q1A10000 1707C712 ON26::9909 ANDAABNEF CrF9SCSC §c5C5C5C 
sescsese scscscsce sesesese sesesese sesesese §cscscse 
scs*5csc 5¢5C5CS5C sesese|ese scesesese Ssecsesese §c¢5c5cC5C 
scescscsce §csc5csc scesesese sesescese sesesese) 6 §5c05¢C5C5C 
sescescsce $cscsce#o | afananan SNanen4an 4AENnanen 4ycAanK4nKND 
8Oo4n4so4o #0404040 aNananan sAnanansaq ananansan c4#o404a 
49404049 40404049 anangnan 4anananan anananan 4cK4o4anen 
49494040 4040404) SN4EDKNGD NaNnanan 4ansconnn g23natan 
025c0000 O288001F ABONIFAF OALFS83n? 

PRIME FILE BLOCK NO. 90008C BLOCK LENGTH 35 SECOND FILE BLOCK NO. annonce BLOCK LENGTH Sy 
onooccss 03221200 11N9ennnH = As7anAgAN OFaNNNAN n7380Nn00 
oosaaooe a2c00030 ANIFAANN IFOaNOIF) ANKNEL39N )§«6NzO030N00 
00000000 9g000G01IF ANNAASD3 NACICHED 4 nananie A$009000 
03900000 90000001 ANCSNOSc4a N3C9C24N = aNnsesese §cScSCSC 
sescscse scscesese sesesese sesesese sesesesc | §sc5cscse 
sescses5c scsesese sesesese sesesese | 6sescsese | 6§9c5¢c5c5¢ 
sescscsc SCSC5C490 «4#NaNnanan 4aNnansnan 4nananan 4caneo4an 
49404040 40404040 4N4nenan 4sOnananan 4anananen 4¥foeneosn 
40404040 40404040 ananangn 4nananan #nenangny 4o494n4o 
40404040 40404040 48N4NeNEN 4N4NeN4N 4NsSeanon 492300000 
o25co00nN a28sanolF ABNOLFAF DNLIFR D2 

LIBRARIAN FINISHEO 

OATE 88/07/08 TIME 16.18 

TOTAL NUMBER OF ERRORS QGO0GO UPSI SETTING x*Q0° 

S Figure 3-2. Sample Librarian Map for a File Compare Operation (Part 3 of 3) 
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® 3.3.10. Correcting Modules (COR and EOD) 


Function 


The librarian can correct records within any type of module by processing 
correction statements that define the corrections. The COR librarian control 
statement identifies the beginning of a series of correction statements for a 
module. It includes the name of the input file containing the module to be 
corrected, the module type, the module name, and the output file where the 
corrected module is to be placed. The EOD statement identifies the end of the 
series of correction statements. 


Instructions for correcting program source or macro/jproc source modules are 
given in 3.3.11. Instructions for correcting object and load modules are given in 
3.3.12. 


Note: When a module is corrected or updated, the header records for the new 
version will specify the date and time that the corrections were made. This 
date and time is normally obtained from the system information block. 
However, the | | PARAM UPDATE statement may be used in the librarian 
job control stream to override the system setting and specify another date 
and time to be used. See 2.6.4 for more information. 


Format 









LABEL AOPERATIONA OPERAND 


\ 


[, VERASG=n/n/n] 






unused CORE .options] ,Name[ ,output-lfn3L,n€/nl/n371 





s 
| 
ie) 
L 


LABEL AOPERATIONA OPERAND 
unused EOD unused 
Options 


UP-8841 Rev. 4 


E- The first EOD statement identifies the end of the correction statements. 


N- Do not list module header information, correction statements, or any records 
added, deleted, or changed on the librarian map. 


P- Punch a copy of the corrected module on cards. 
X- Extend the load module if any of the supplied patch addresses are beyond 


the end of the module. This option is only valid when a single-phase load 
module is being corrected. 
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Note: There is no D option to list the corrected module. Instead, the COP 
librarian control statement described in 3.3.17 can be used following the 
EOD statement that indicates the end of the correction cards. 


Positional Parameter 1 


input -tfn 
Specifies the logical file name of the file containing the module being 
corrected. 


If omitted, the job run file $Y$RUN is assumed. 
Positional Parameter 2 


S,M,0,L, 
Specifies the type of module being corrected as either program source (S), 
macro/jproc source (M), object (O), or load (L). 


Positional Parameter 3 


name 
Specifies the name of the module being corrected. 


Positional Parameter 4 


output-l fn 
Specifies the logical file name of the file where the corrected module is to be 
placed. 


This parameter may be omitted if the input file is a disk or format label diskette 
file. If omitted, the old version of the module is deleted and the corrected version 
is added to the end of the input file. If the input file is a tape or data set label 

diskette file, this parameter is required and must be different than the input-lfn. 


Positional Parameter 5 


n/n/n 
Specifies the version and subversion numbers, if included, of the library 
module being corrected. The value of each n is any decimal number from 0 to 
256. When specified, a match of the version numbers is required. Otherwise, 
the correction process is terminated and a diagnostic message printed. If 
omitted, no checking takes place before the correction is made. 


Each time a correction is made by the correction (COR) function, the third 


subversion number of the module is incremented by 1. This provides a 
history of how many times the module has been corrected. 
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Keyword Parameter 


VERASG=n/n/n 
Specifies the version number to ':2 applied to the module being corrected. 
(Should be specified as last n>~.....eter when used with positional 
parameters.) 


Example 1 





COR D1,S,OLDEXP1,D2 


: Correction cards 
EOD 


Corrects the source module named OLDEXP1 in file D1 as specified by the 
correction cards and adds the corrected version to file D2. 


Example 2 


1 10 16 





COR =, S, OLDEXP2,D3 


- Correction cards 
EOD 


Corrects the source module named OLDEXP?2 in the job run file $Y$RUN as 
specified by the correction cards and adds the corrected version to file D3. 


Example 3 


1 18 16 





COR 01,S,EXAMPLE3 


- Correction cards 
EOD 
Corrects the source module named EXAMPLES in file D1 as specified by the 


correction cards. Deletes the old version EXAMPLES in file D1 and adds the new 
version to the end of file D1. 
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3.3.11. Correcting Source Modules 


The librarian can be used to make the following kinds of corrections to program source 
and macro/jproc source modules: 


eo Replace records 

¢ Insert records 

¢ Delete records 

¢ Rearrange records 

e Resequence the corrected module 

The changes are specified by correction cards that are placed between the COR and 
EOD librarian control statements. These correction statements may include any 


combination of the following: 


e SEQ librarian control statement to identify the sequence number field in the 
module being corrected and, optionally, to resequence the corrected module. 


¢ New source records to insert into the module. 


¢ New source records to replace existing records. 





e SKI librarian control statements to skip records in the original module. 


¢ REC librarian control statements to recycle the pointer to the beginning of the 
original module. 


These correction statements are a series of instructions on how to correct the module. 
The librarian corrects a module not by modifying the original but by building a new 
module according to this series of instructions. To do this, the librarian reads the 
original module record by record. It determines when to make a change by comparing 
the sequence number of the current record to the sequence number in the next 
correction statement. If the current record is not affected by that statement, the 
librarian adds the current record to the end of the new module that it is building. The 
librarian then advances to the next record in the original module and compares its 
sequence number to the number in the correction statement. Thus, the librarian only 
processes the next correction statement when it reaches the appropriate position in 
the original module. With this method, it may be necessary to make several passes 
through the original module to rearrange records. This is illustrated in the REC 


example later in this section. 


Because record sequence numbers are critical in correction operations, a source 
module must be sequenced before it can be corrected. It can be resequenced as it is 
corrected by using a SEQ statement immediately after the COR statement (see the 
SEQ librarian control statement, which follows, for instructions). When the correction 
statements are out of sequence, they are flagged and the module is not corrected. 
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After processing all the correction cards, the librarian deletes the original version of 
the module and places the corrected version in the output file specified in the COR 
statement. 


Specifying the Sequence Control Field (SEQ) 
Function 


When the SEQ librarian control statement is used immediately after the COR 
statement, it can serve the following two functions: 


1. To identify column positions used for sequence numbers in the source 
module being corrected. 


2. To specify the starting sequence number and increment if the corrected 
module is to be resequenced. 


The corrected module always uses the same column positions for the sequence 
numbers as the original module. 


The SEQ statement is not necessary if the original module contains sequence 
numbers in the default column positions 73 through 80 and the corrected module 
is not to be resequenced. If the SEQ statement is omitted, any records inserted 
during the correction operation will not have sequence numbers. 


Note: If any records in the original module do not have sequence numbers, the 
module must be resequenced before the corrections are processed. To do 
this, use a SEQ statement before the COR statement (see 3.3.7). 


Format 





AOPERATIONA 






home} (ae | 


80000000 





Options 


Ignored 
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Positional Parameter 1 


lfn 
Specifies the logical file name of the file containing the module being 
corrected. 


If omitted, the job run file $Y$RUN is assumed. 
Positional Parameter 2 


S,M 
Specifies the type of module being corrected as being either program source 
(S) or macro/jproc source (M). 


Positional Parameter 3 


name 
Specifies the name of the module being corrected. 


If used, it causes the module to be resequenced and must be the same as the 
module name used in the COR statement. If omitted, the SEQ statement only 
identifies the characteristics of the sequence numbers in the module. 


Positional Parameter 4 


column @ 


Specifies the starting column for the sequence number in each module 
record. If omitted, column 73 is assumed. The length of the content 
parameter determines the length of the sequence number field. 


Positional Parameter 5 


content 
Specifies the sequence number for the first record in the corrected module. 
This string can be from one to eight characters long. Its length determines 
the maximum length for any sequence number in the module. It may contain 
letters, digits, or both; if any letters are used, all the letters must be 
contiguous and precede any digits. For example, MA400, GRP000, and 
10000001 are valid sequence numbers. However, M4A00, 600MAST, or 
22AAA33 are not valid. 


SAME 
If the module is being resequenced, SAME specifies that the eight-character 
sequence number for the first record in the corrected module is to be the 


same as the one in the original module. 


If this parameter is omitted, the sequence number used for the first record is 
eight zeros (00000000). 
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Positional Parameter 6 
increment 
Specifies a decimal number from 0 to 255, to be used as an increment for the 
sequence numbers of successive records. 


If omitted, the value 1 is assumed. 


Example 1 





COR 1,S,EXP1 
SEQ D1,S,EXP1,1,SRC100 


EOD 


The source module being corrected is EXP1 in file D1. Its sequence numbers are 
to begin in column 1 and are six characters long. The corrected module is to be 
resequenced with a sequence number of SRC100 for the first record and the 


default increment of 1. 
@ Example 2 
1 10 3 16 





COR 02,S,EXP2 
SEQ D2,S,EMP2,1,SAME, 10 


EOD 
The source module being corrected is EXP2 in file D2. Its sequence numbers are 
to begin in column 1 and start with the same sequence number as the first record 
in the original module. The increment is to be 10. 

Example 3 


1 10 16 





COR D3,S,EXP3 
SEQ D3,S,EXP3,,,20 


EOD 
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The source module being corrected is EXP3 in file D3. Its sequence numbers are 
to begin in the default column positions 73 through 80. The corrected module is to 
be resequenced in columns 73 through 80 starting with the default value of 
00000000 for the first record and an increment of 20. 


Example 4 





COR 04,S,EXP4 
SEQ D4,S,EXP4 


EOD 


The source module being corrected is EXP4 in file D4. Its sequence numbers are 
described by the default parameters. Resequence the corrected module using 
those same parameters. 


Example 5 


See Example 2 in “Replacing and Inserting Records,” which follows in this 
section. 





Replacing and Inserting Records 


The correction statement for a new record or a replacement record contains the actual 
source module record itself. To cause a record to be replaced, the sequence number 
used on the correction statement must be in the same column positions and have the 
same value as the record being replaced. When a series of records is being inserted in 
the same place, only the first new record needs a sequence number. This sequence 
number should be within the range between the two existing records. Any additional 
records to be inserted at that point can be placed immediately after the first new 
record. They must be in the correct order. 


The librarian map lists insertions and replacements as follows: 


¢ For record replacements, the complete original record is listed followed by its 
replacement. The original record is preceded by five minus signs (-----) and the 
replacement record is preceded by five plus signs (+++++). 


¢ For record insertions, the original record preceding the inserted records and all 
the inserted records are listed in order. Each inserted record is preceded by five 
plus signs (+++++). 


If any new records are out of sequence within the correction deck, they are flagged and 
the module is not corrected. 





340 UP-8841 Rev. 4 





Librarian Control Statements 


Notes: 


1, 


If the /$ or /* job control statements are among the correction statements, there 
must be a /$ for each /* statement so that the /* is not interpreted as the end of the 
librarian control statements. 





2. Ifthe module being corrected is a librarian control stream, the correction 
statements may include EOD librarian control statements as new records to be 
inserted. Unless the E option is used in the COR statement, the librarian does not 
terminate the corrections until it encounters an EOD statement that does not have 
a corresponding COR or ELE statement. 

Example 1 

1 10 16 72 
COR 0@,S,COBOL1 
@2 ACCT-NO PIC 9(4). COBO165@ 
@2 FILLER PIC X(4). COBO2 100 
@2 ACCT-NO-OUT PIC 9(4). COBQ2650 
MOVE ACCT-NO TO ACCT-OUT. COB@3750 
MOVE SPACES TO PRINTLINE. C0B03820 
WRITE PRINTLINE. COBO3848 
MOVE SPACES TO PRINTLINE. c08e4028 
WRITE PRINTLINE. COBQ4049 
MOVE SPACES TO PRINTLINE. COB04420 
WRITE PRINTLINE. COBO4440 
EOD 
These correction statements are new records or replacement records for the 
source module COBOL! in file DO. Because the sequence numbers are in the 
default column positions 73 through 80, no SEQ statement is required after the 
COR statement. 
Example 2 
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COR D1,S,RPGSAMP 
SEQ 01,S,RPGSAMP,3,01@ 


O551F 1 8 PHONIN 
675C MOVE PHONIN PHONOT 8 
O950F PHONOT 

EOD 


These correction statements insert three new records in the source module 
RPGSAMP, which is an RPG II program in the file D1. The sequence numbers 
055, 075 and 095 used in the program are in columns 3 through 5. (IF, C, and OF 
are the beginning of the source statements that start immediately in column 6.) 
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342 


Because columns 3 through 5 are not the default column positions used for 
sequence numbers, a SEQ statement is needed after the COR statement to 
identify their location. The fourth parameter in the SEQ statement specifies that 
the sequence numbers start in column 3. The fifth parameter, 010, is the 
sequence number used for the first record in the original module; its length 
indicates that the sequence numbers have a maximum length of three characters. 


Skipping Records (SKI) 
Function 


The SKI librarian control statement causes the librarian to skip records in the 
original module as it processes corrections. The SKI statement specifies sequence 
numbers of the first and last records to be skipped. When it encounters the SKI 
statement, the librarian advances the pointer past this range of records without 
copying them to the corrected module. 


The SKI and REC statements may be used together to rearrange records, as 
described in “Rearranging Records (REC),” which follows in this section. 


Format 

LABEL AOPERATIONA OPERAND SEQUENCE 

unused SKI[ options] last-sequence-no {starting-sequence-no] 
Options 


D- List the records skipped on the librarian map. 
Positional Parameter 1 


lLast-sequence-no 
Specifies the sequence number of the last record in the series to be skipped. 


Sequence Field Value 


starting-sequence-no 
Specifies the sequence number of the first record to be skipped. 


This value must be placed in the same column positions used for the sequence 
number field in the original module. These are the default column positions 73 
through 80 or the column positions specified in the SEQ control statement used 
after the COR statement (see “Specifying the Sequence Control Field (SEQ)” 
earlier in this section). 


If omitted, the skip operation begins immediately after the last record processed 
by the last COR statement. 
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Examples 
1 10 16 73 
1. SKI  AAA5@@ AAA5OO 
2. SKI COB14@0 COB 1108 
3. SKI LIBS2008 


1. Skips record AAA500. © 
2. Skips all records between COB1100 and COB1400, inclusive. 


3. Skips all records from the current record up to and including record 
LIBS2000. 


Figure 3-3 illustrates a) the original source module, b) the corrected source module, 
and c) the librarian control statements used to make the corrections. 
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1 10 16 72 
TESTEXAM EQU E LINK#180 
CR RO.W3 LINKS280 
BE LKS3PA28 LINK#308 
BH LKS3PA16 LINK#8400 
M W2.LK$CSGS2Z LINKO508 
L W2.LKSCSEGT LENK#60@ 
{Cc W3,.0(W2.W3) LINK@708 
N W3.LKSCX7F LENKO8098 
BNZ LKS3PA08 LINK9968 
LA W3.LKSCROOT LINK1080 
TESTEXAL EQU ° LENKI100 
LR RO, W3 LINK1299 
LA RRTNOD. 4 ; LENK1390 
B LKS$CPOP LUNK1400 
BAL R14. LBSCSTK LENK1509 


a. Source module 





COR DO.S.TESTEXAM 


1. CR R1,W2 LINKO268 
2. XR W2,W2 LINKO458 
3. SKI LINK#880 LINK#88B 
4. 


SKI LINK1468 LINK1199 
E00 


b. Correction deck 














1. Replacement record for source record with sequence number LINKO200. 
2: New source record to be inserted between the source records with sequence numbers LINKO400 and LINKOSOO. 
3. Skip instruction which skips record LINKO800, causing it to be omitted from the corrected module. 
4. Skip instruction for all records between LINK1100 and LINK 1400, inclusive. 
1 10 16 72 
TESTEXAM EQU . LINK#188 
CR R1.W2 LINK#208 
BE LKS3PA286 LINK8399 
BH LKS3PA18 LINK8409 
XR W2 .W2 LINKO459 
M W2,.LKS$CSGSZ LINK@508 
L W2.ULKSCSEGT LINKO609 
Ic W3.8(W2.W3) LINK97998 
BNZ LKS3PA08 LINK9998 
LA W3.LKSCROOT LINK1099@ 
BAL R14,LBSCSTK LINK1596 





c. Corrected source module 


Figure 3-3. Sample Source Module Correction 
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Rearranging Records (REC) 
Function 


The REC librarian control statement recycles the pointer during source module 
corrections. It resets the pointer to the first record in the original module. The 
REC statement can be used with the SKI statement to rearrange records in a 
program source or macro/jproc source module. 


The sequence number field in the REC statement specifies when the pointer is to 
be repositioned. When the REC statement is processed, all records from the 
current record up to and including the record specified in the REC statement are 
copied to the new module. Then the pointer is reset to the first record. If the 
sequence number field in the REC statement is blank, the pointer is reset 
immediately. 


When records are rearranged, they retain their same sequence numbers in the 
corrected module unless there is a SEQ statement after the COR statement to 
resequence the corrected module (see “Specifying the Sequence Control Field 
(SEQ)’ earlier in this section). 


Note: The REC statement cannot be used to correct modules on tape or data set 


label diskette. 
® es 


LABEL AOPERATIONA OPERAND SEQUENCE 


unused REC unused [last-sequence-no] 
Options 

None 
Sequence Field Parameter 


last-sequence-no 
Is the sequence number of the last record to be copied to the new module 
before the pointer is reset to the beginning of the original module. 


This value must be placed in the same column position used for sequence 
numbers in the original module. 


If omitted, the pointer is reset immediately when the REC statement is 
processed. 


Example 


Figure 3-4 illustrates a) the original source module, b) the corrected source 
) module, and c) the librarian control statements used to make the corrections. 
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1 10 16 73 
ORIGINAL RECORD LIBSO90® 
ORIGINAL RECORD L1BS0100 
ORIGINAL RECORD LIBS0200 
ORIGINAL RECORD L1BSO300 
ORIGINAL RECORD LIBSO8@0 
ORIGINAL RECORD LIBSO400 
ORIGINAL RECORD LIBS®600 
ORIGINAL RECORD LIBSO700 
ORIGINAL RECORD LIBSO500 
ORIGINAL RECORD LIBS1000 


Original Source Module 





ORIGINAL RECORD LIBS0100 
NEW RECORD ‘ LIBSO200 
ORIGINAL RECORD LIBS830¢ 
ORIGINAL RECORD LIBS0400 
NEW RECORD LIBS@500 
NEW RECORD LIBS@550 
ORIGINAL RECORD LIBS0600 
ORIGINAL RECORD L1BS0700 
ORIGINAL RECORD LIBSO800 | 
ORIGINAL RECORD LIBS0900 
ORIGINAL RECORD LIBS1000 


b. Corrected Source Module 





COR DO,S,EXAMPLE1 





1. SKI LIBSO900 

2. | NEW RECORD LIBSO200 
3 SKI LIBSO800 LIBS0800 
4. SKI LIBSO700 LIBS0600 
5. REC : 

6 SKI L1BS04060 LIBS0900 
7. | NEW RECORD LIBS0500 
8. | NEW RECORD LIBS@550 
9. REC LIBS0700 
10. SKI LIBS0300 LIBS0900 
11. REC LIBS0800 
12. SKI LIBS0500 LIBSO100 

EOD 


c. Correction Statements 





Figure 3-4. Example Using SKI and REC Statements to Rearrange Records (Part 1 of 2) 
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Skip original record LIBSO900. Copy original record LIBSO100. 

Use new record LIBSO200 instead of originai record LIBSO200. Copy original record LIBSO300. 
Skip original record LIBSO800. Copy original record LIBSO400. 

Skip original records LIBSO600 and LIBSO700. 

Recycle the pointer to the beginning of the original module. 

Skip original records LIBSO900 through LIBSO400, inclusive. 

Use new record LIBSO500 instead of original record LIBSO500. 

Insert new record LIBSO550. 


Copy all original records from current record (LIBSO600) to LIBSO700. Recycle the pointer to the beginning of 
the original module. 


Skip original records LIBSO900 through LIBSO300, inclusive. 


Copy all original records from the current record (LIBSO800) to LIBSO800, inclusive. (Only one record is 
copied.) Recycle the pointer to the beginning of the original source module. 


Copy all original records from the current record (LIBSO900) up to, but not including, LIBSO100. Skip all 
records from LIBSO100 through LIBSO500, inclusive. Copy all remaining records from the current record 





(LIBS 1000) to the end of the original module. (Only the record LIBS 1000 is copied.) 





Figure 3-4. Example Using SK! and REC Statements to Rearrange Records (Part 2 of 2) 


3.3.12. Correcting Object and Load Modules 


Function 
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The instructions and data needed to correct, or patch, an object or load module 
are supplied to the librarian through correction cards. These correction cards 
must be placed between the COR and EOD librarian control statements. Each 
correction card may contain text data, relocation data, or an ORG directive that is 
used to set or reset the location counter. 


Text patches are inserted in the module being corrected just after the last current 
text record and just ahead of the transfer record. Then, whenever the appropriate 
load module is loaded into main storage, or the object module is linked, the new 
text is inserted in the appropriate place in the module, overlaying the old text. 
When patched object modules are listed, the patches are indicated by asterisks. 


For phased load modules, the patches must be correctly sequenced by phase 
number. 
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Object module control sections and load module phase sizes may not be altered 
unless the module is a single-phase load module and the X option is used in the 
COR statement. 


If the librarian detects an error within the correction cards, it does not make the 
correction. 


Format 


A correction card for an object or load module must have the following format: 


phase-no 


- address}, { esid-no [, text (before- image) ][,rld]] 
P 
ORG 


Positional Parameter 1 
- | address 
P 
This is the relative address to be assigned to the generated text record. 
A hyphen in column 1 indicates that the address is relative to the object or load 


module base address. The letter P in column 1 indicates that the address is 
relative to the load module phase being patched. 





The address value must be hexadecimal and may be positive or negative. A 
negative address is specified by a hyphen in column 2 followed immediately by 
the address. A positive address value must begin in column 2. 


Positional Parameter 2 


esid-no 
This is the external symbol identification number (ESID) (01 through 255) 
for the object module being corrected. If omitted, the default value 01 is used. 


phase-no 
This is the phase number for the load module being corrected. It must be 
between 00 and 99. If omitted, the default value 00 is used. 


ORG 
This causes the location counter to be set or reset to the address specified by 
positional parameter 1. The current value of the location counter will 
automatically be added to all the addresses specified in subsequent 
correction cards. The location counter will remain set at that value until 
another ORG directive is used or the EOD librarian control statement is 
encountered. If used, the text and rld parameters must be omitted. 
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Positional Parameter 3 


text[(before- image) ] 
Text is a contiguous string of hexadecimal digits to be inserted at the 
address represented by the sum of the most recent ORG directive, if any, and 
the relative address specified by positional parameter 1. The minimum 
amount of text that can be patched is 1 byte. 


Text is required when an ESID or a phase number is specified. If omitted, 
the correction will be flagged and any data included for the rld parameter 
will not be used. 


If ORG is specified in positional parameter 2, this parameter must be 
omitted. 


The before-image subparameter allows you to verify proper field selection 
before applying the correction to that field. The verification process is a 
comparison of the hexadecimal string you provide via this subparameter and 
the code currently existing in the field being corrected. (It is not usually 
necessary to compare all of the text; a comparison of the first few bytes is 
sufficient to verify that the proper field has been selected.) 


If the before-image string matches the existing code, the field is corrected 
with the new text provided. If the new text matches the existing code, the 

@ before-image string is ignored and no error is generated. However, if neither 
the before-image nor the new text matches, a diagnostic error is generated, 
the module is not corrected, and processing continues. 


Positional Parameter 4 
rld 
Relocation data is optional. If used, it must be a string of 3-byte 
(6-hexadecimal-digit) substrings exactly as required. This parameter is valid 
for both object and load modules. 
Notes: 


1. The values supplied for the address, ESID, phase number, and text parameters are 
automatically padded with zeros to the nearest half-byte, if necessary. 


2. Each patch correction card generates a text record. Therefore, contiguous patch 
addresses on succeeding patch correction cards do not cause the text to be merged. 
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Example 1 


The following series of librarian control statements and correction cards are used 
to correct an object module named MYOB in file D2: 


1 18 16 





1. COR 02,0,MYOBJ 

2. -C9@,3,488@D074 

3. +1868, ,0001250,011F80191FOe 

4. +2946, 255, FOF 1F2 

5. EOD 

1. Identifies the module being corrected as the object module named MYOBJ in 
file D2. 

2. Patches the specified load half-word instruction into hex address 0C90. The 
text record CSECT base ESID is 3. No relocation data is specified. 

3. Patches the specified full-word address constant into hex address 1868. The 
text CSECT base ESID is 1, the default. Two relocation masks are included, 
each with full modification to the address constant, once with ESID#1 value 
and once with ESID#19 value. (For RLD formats, see Figure B-2.) 

4, Patches the three EBCDIC characters 0, 1, and 2 at hex address 2946. The 
base ESID is 255. 

5. Indicates the end of the patch cards. 

Example 2 


The following series of librarian control statements and correction cards are used 
to correct a multiphase load module named MYLOAD. The original version 
resides in file DO; the patched version is to be placed in file D2. 


1 18 16 





COR D@,L,MYLOAD,D2 
-C90, ,4880D074 
P12D, 1,9540C012 
-0124, ORG 
P250,3,AB 
--4B78, ORG 
-5672,4,@A1C 
-@, ORG 
-D2E, 6, @0012E ,061F G0 
EOD 


= OANA URE WD = 
. 8 «© «© © 8 « «© & 


UP-8841 Rev. 4 











Librarian Control Statements 


1. Identifies the module being corrected as load module MYLOAD in file DO. 
The corrected version of the module is to be added to file D2. 


2. Applies the specified text to load module address C90 of phase 0. 
3. Applies the specified text to address 12D relative to the start of phase 1. 
4. Sets the location counter to 0124. 


5. Applies the specified text to address 250+124 relative to the beginning of 
phase 3. 


6. Resets the location counter to -4B78. ~ 

7. Applies the specified text to load module address 5672-4B78 in phase 4. 
8. Resets the location counter to 0. 

9. Applies the specified text to relative address D2E in phase 6. 


10. Identifies the end of the correction cards. 


3.3.13. Blocking Load Modules (BLK) 


& Function 


The BLK librarian control statement converts a standard load module to a 
blocked load module. The blocked version may then be placed in a new file or may 
replace the unblocked version in the same file. 


Blocked load modules can be loaded more efficiently than standard, unblocked 
load modules. For a standard load module, each phase is loaded 256 bytes at a 
time. For a blocked load module, the loader can read each phase (or up to an 
entire track) in a single I/O operation. This requires fewer disk accesses to load 
the entire module. 


Files containing blocked load modules use three partitions, rather than two like 
all other SAT files. The first partition is still used for a directory. The load 
module records in the second partition are data records that define the 
boundaries of each phase in the third partition. The third partition is 
unstructured and contains contiguous text data, free of any control information. 
This text data is in sequential load order and is binary zero-filled when 
appropriate. 


UP-8841 Rev. 4 351 





Librarian Control Statements 








In standard load format, no text records can be overlaid; however, in blocked 
format, they can. For example, this overlaying would occur when the load module 
detects the following coding: 


Location Operation Operand 
0000 CLI R6,Xx‘01’ 
0004 BC 8,STOR1 
0004 ORG *.4 

0004 BC 15,STOR2 


The BC 15 overlays the BC 8. In standard load module format, the bytes of text 
for the BC 8,R1 continue to exist in the module although they are overlaid at load 
time. 


The following points should be considered in determining whether to convert a 
standard load module to blocked format: 


¢ Modules less than 4K bytes in length take longer to load if blocked, unless 
the resident loader named RESMOD.SM$LOD is used. 


* Do not block assembler language program modules that have information 
passed from one phase to the next in a DS area. All DS areas are zero-filled. 


¢ Do not block assembler language program modules that have address 
constants overlaid with text. This can occur when an unneeded address 
constant is used for patch space. It can also occur when an ORG directive is 
used to overlay an address constant with instructions. 





¢ Patches slow down the loading of blocked load module phases more than 
standard load module phases. 


Notes: 


1. A blocked load module can be copied to and from a tape, using a COP control 
statement (see 3.3.5) and can be corrected to and from tape. 


2. If the blocked load module is output to a file that already contains a load 
module with that name, the old one is deleted and the new one is added to the 
file. 


3. Load modules generated from ANSI 1974 COBOL source code that include 
the dynamic CALL or CANCEL verbs cannot be converted to blocked format. 


Format 
LABEL AOPERATIONA OPERAND 
unused BLK input - | fn,name[ ,output-l fn}, VERSAG=n/n/n) 
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Options 
None 
Positional Parameter 1 


input-l fn 
Specifies the logical file name of the file containing the standard load 
module. 


Positional Parameter 2 


name 


Specifies the name of the standard load module. 
Positional Parameter 3 


output-l fn 
Specifies the logical file name of a disk or format label diskette file in which 
the blocked load module is to be saved. 


If omitted, the blocked load module is added to the end of the input file and the 
standard load module is logically deleted. This parameter is required if the 
original module is on a tape or format label diskette. 


Keyword Parameter 


VERASG=n/n/n 
Specifies the version number to be applied to the blocked load module. 
(Should be specified as the last parameter when used with positional 
parameters.) 


Examples 
1 10 16 


1. BLK D1, STEP2,02 
BLK D3, STEP3 


1. Converts the standard load module named STEP2 in file D1 to a blocked 
load module and adds the blocked version to the end of file D2. File D1 
retains the standard load module. 


2. Converts the standard load module named STEP3 in file D3 to a blocked 
load module. The standard version is deleted and the blocked version is 
added to file D3. 
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3.3.14. Renaming Modules, Groups, and Records (REN) 
Function 
The REN librarian control statement is used to: 
e Rename a single module or module group 
¢ Rename all modules with the same name 
¢ Rename a record in an object or load module 
e Mark an object or load module as shareable or unshareable 
e Add or change the comment in a module header record 
When a module name is changed, any other module in the file with the new name 


and the same type is deleted. When a load module name is changed, the new © 
name is reflected throughout each phase. 


Note: The REN control statement cannot be used for files on tape or data set 
label diskettes. 


Format 







AOPERATIONA OPERAND 









REN[ .options] 


r-oxn 


RON 
ROFF 


,old-name |. an 
C,new-namej{ ,comment ] 
Options 

G- Rename the next group with the group name specified by old-name. 


N- Do not list module header records on the librarian map. 
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Positional Parameter 1 
t 


Specifies the logical file name of the file that contains the modules to be 
processed. 


lfn 


If omitted, the job run library $Y$RUN is assumed. 
Positional Parameter 2 
$,M,0,L 
Specifies the type of modules to be processed as either program source (S), 
macro/jproc source (M), object (O), or load (L). 


If omitted, all modules with the name specified by old-name are processed. The 
type parameter is not valid when the G option is used. 


Positional Parameter 3 


RON 


old-name|. { record- type-and-name 
ROFF 


& Old-name identifies the module or module group (with G option) to be 

processed. If record-type-and-name, RON, or ROFF is used, a period is 

needed as a separator. 
The record-type-and-name is required if an object module record name or an alias 
phase name of a load module is being changed. This value consists of a letter for 
the record type plus the old record name combined in a single string. The valid 
record types and their meanings are as follows: 

C: - COM record 

E - ENTRY record 

N - procedure name record 

P -alias-phasename of a load module 

S -CSECT record 

V -V-CON record 

X - EXTRN record 


For example, the value MASTER.XTAGS for this parameter specifies that the 
EXTRN record named TAGS in the module MASTER is to be renamed. 
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RON or ROFF is required after the old name if the shareability status of an 
object module is being changed. RON specifies shareable and ROFF specifies 
unshareable. 


Positional Parameter 4 


new-name 
Specifies the new name for the module, module group (with G option), or 
record. It can be up to eight characters long, except for a multiphase load 
module name, in which only the first six characters of the name can be 
changed. 


This value must be omitted if the shareability status of a module is being 
changed or only the comment in a module header record is being added or 
changed. 
Positional Parameter 5 
comment 
This is a string of up to 30 characters to be included in the header record of 
the specified module or group. 


If omitted, the current comment remains the same. 


Examples 





REN D1,S,EXP1,NEWEXP1 

REN.N D2, ,EXP2, NEWEXP2 

REN 0, EXP3, NEWEXP3 

REN 4,0, EXP4.SCS0041, CS@042 
REN.G DS, ,EXP5, NEWEXP5 

REN 06,S,EXP6,,REVISED BY EJM 
REN D7, L,EXP7.RON 


Nou fF WN = 
. 28 © « «© «@ 8 


1. Renames the source module EXP1 in file D1 to NEWEXPI1. 


2. Renames all modules of any type named EXP2 in file D2 to NEWEXP2. The 
header information for these modules is not printed on the librarian map. 


3. Renames the object module named EXP3 in the job run library $Y$RUN to 
NEWEXP3. 


4, Renames the CSECT record named CS0041 in the object module named 
EXP4 that resides in file D4. The new name is CS0042. 


5. Renames the next group named EXP5 in file D5 to NEWEXP5. 
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6. Adds the comment REVISED BY EJM to the header record of the source 
module EXP6 in file D6. 


7. Makes the load module named EXP7 in file D7 shareable. 


3.3.15. Compressing a File (PAC) 


Function 
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The PAC librarian control statement physically erases modules that have been 
deleted and moves the remaining modules toward the beginning of the file. As a 
result, all unused file space is at the end of the file. The PAC statement can be 
used only for disk or format label diskette files. 


Modules are deleted by the DEL librarian control statement or by any statement 
that causes an existing module to be replaced or updated. Deleted modules still 
occupy space in the file, but are identified as being nullified in the file directory. 


Because the PAC operation permanently removes a module, it may be desirable 
to only use it occasionally. A version of the COP statement is available to copy all 
but the nullified modules from one file to another (see 3.3.5). 


On the librarian map, the PAC statement is followed by the header information 
for all of the modules in the file. Those that were not packed are listed under the 
heading MODULES NOT MOVED. Any modules that were packed are listed 
under the heading MODULES MOVED. 


Notes: 


1. The PAC statement can be used only for disk or format label diskette files. To 
achieve the equivalent result in a tape file or a data set label diskette file, use a 
COP statement to copy all but the deleted modules from the original tape to a 
new one (see 3.3.5). 


2. The file being packed should be lockable, giving the current user exclusive 
access. For a description of the file lock facility, see the Data Base 
Management System (DMS) System Support Functions Programming Guide 
(UP-10870). 


3. Afile being packed cannot be updated. 


4. Whena load file is being packed, the pack operation must be completed before 
a program is executed from the file. 


5. The PAC control statement should not be used for a file that contains an 
active ICAM symbiont. 


6. The PACKRES canned job control stream is available to compress files on a 
system release volume. See 3.5.4 for information. 
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7. Ifthe $Y$LOD library is packed, the fast-load capability is disabled, reducing @ 
system efficiency. You must reinitialize (re-IPL) the system to regain the fast- 
load capability. 


Format 








AOPERATIONA OPERAND 


PAC[ .options] 


Options 
N- Do not list the module header information on the librarian map. 
Positional Parameter 1 


lfn 
Specifies the logical file name of the file that is being compressed. 


If omitted, the job run file $Y$RUN is assumed. 


Examples 





1 18 16 
1. PAC D1 
2. | PAC.N D2 
1. Erases all logically deleted modules in file D1. 
2. Erases all logically deleted modules in file D2. Module header information is 


not printed on the librarian map. 


3.3.16. Printing a File Table of Contents 


Printing an Alphabetical Table of Contents (LST) 
Function 


The LST librarian control statement prints an alphabetical table of contents of all 
modules in a file or only modules of a specified type. The list includes the module 
type, name, creation date, and creation time. 


Note: The LISTRES and DRDP canned job control streams are available in the 
system to print directories of files on a system release volume. See 3.5.1, 
3.5.2, and Appendix A for more information. 
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Format 


LABEL AOPERATIONA OPERAND 





Options 
None 
Positional Parameter 1 


lfn 
Specifies the logical file name of the disk or diskette file to be processed. 


If omitted, the job run file $Y$RUN is assumed. 
Positional Parameter 2 
S,M,0,L 
Specifies the module type to be processed as either program source (S), 
macro/jproc source (M), object (O), or load (L). 
If omitted, all modules in the file are listed. 


Examples 


1 18 16 





2. LST 2 
3. Lst ,S 
4. LST 


1. Prints an alphabetical list of all load modules in file D1. 
2. Prints an alphabetical list of all modules in file D2. 
3. Prints an alphabetical list of all source modules in the job run file $Y$RUN. 


4. Prints an alphabetical list of all modules in the job run file $Y$RUN. 
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Printing a Sequential Table of Contents (COP) 
Function 
ACOP librarian control statement with only an input file parameter prints a 
sequential table of contents for a file. The list includes the type, name, creation 
date, and creation time for all modules in order as they occur in the file. The D 
option may be used to list all entries in the file directory (see 2.3.1 for a 
description of a disk file directory). 
The table of contents begins on a new page on the librarian map. 
Notes: 
1. Other uses of the COP statement are explained in the sections indicated: 
© Resetting the pointer in a file (3.3.2) 
© Copying modules and files (3.3.5) 
e Listing and punching modules (3.3.17) 
2. The LISTRES and DRDP canned job control streams are available in the 
system to print directories of files on a system release volume. See 3.5.1, 3.5.2, 
and Appendix A for more information. 


Format 








AOPERATIONA OPERAND 


input-lfn 
$YSRUN 


LABEL 


unused COP[ .options] 





Options 

D- Print all records in the file directory. 

If omitted, header information for all modules in the file are listed. 
Positional Parameter 1 


input-lfn 
Specifies the logical file name of the file to be processed. 


If omitted, the job run file $Y$RUN is assumed. 
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Examples 
1 18 16 
1. cop 1 
. COP.D 02 
3. cop 


1. Prints a sequential list of all modules in the file D1. 
2. Prints a sequential list of all directory entries in the file D2. 


3. Prints a sequential list of all modules in the job run file $Y$RUN. 
3.3.17. Listing and Punching Modules 


How Modules Are Listed and Punched 
Module listings are printed on the librarian map. 


Source modules are listed one record per line or punched one record per card, exactly 
as they are coded. Each record up to 80 characters in length (including the sequence 

@ number) requires one card or one printed line. Records with more than 80 characters 
require more than one card. 


Program source and macro/jproc source modules will be printed in hex format if the 
statement // PARAM PRTOBJ=ON is used between the // EXEC LIBS and /$ job 
control statements. This is effective for the entire librarian job step. 


For object or load modules, the librarian lists or punches 80-byte records containing a 
5-digit sequence number in columns 1 through 5 and object or load code in 
hexadecimal format in the remaining 75 columns. To do this, the librarian divides the 
code into 75-byte intervals. When the module is copied back to a disk, tape, or diskette 
file, the module is reassembled as it originally existed. 


When the librarian punches a module, it does not punch the module header record.. 
Instead, it punches an ELE card before the first record in the module and an EOD ¢ 
card after the last record in the module. The logical file name D1 is always used on the 
ELE card along with the name and type of the module being punched. For example, 
the following ELE and EOD cards would be punched for a source module named 
SAMPLE: 


ELE} D1,S,SAMPLE 
EOD 


Note: A source module punched on cards should be sequenced so that the librarian 
can automatically check the order of the records as it reads them. A module can 
be sequenced before or after it is punched using the SEQ librarian control 

@ statement described in 3.3.7. 
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List and Punch Options as Secondary Operations (D and P Options) 


This section explains how to list or punch modules without performing any other 
operation. However, all modules processed by the following librarian control 
statements can be listed or punched at the same time by including a list option (D) or 
a punch option (P) in the statement. Refer to the section indicated for more 
information: 


COP 3.3.5 
COR (punch only) 3.3.10 


DEL 3.3.6 
ELE | 3.3.4 
REPRO 3.3.19 
SEQ 3.3.7 


Note: The MODLST canned job control stream is available in the system to print 
listings of modules in a system release volume. See 3.5.3 for information. 


Listing or Punching Modules as the Only Operation (COP) 





Function 


This COP librarian control statement (with no output file parameter) is used to list or 
punch modules in a file. No modules are copied, as when an output file parameter is 
included in the COP statement (see 3.3.5). 


The list option (D), the punch option (P), or both may be specified in the same COP 
statement. Other options and parameters used in the COP statement specify the 
modules to be listed or punched. 


Note: The MODLST canned job control stream is available in the system to print 
listings of modules in a system release volume. See 3.5.3 for information. 


Format 








AOPERATIONA 










LABEL OPERAND 








COPL .options] 
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Options 


A- Process all groups in the file with the group name specified by the name 
parameter. The G option is also required. 


C- Without the G option, the name specified in the name parameter is a module 
name prefix. With the G option, the name is a group name prefix. 


D- Prints listings of all the modules specified. 

G- Without the C option, the name parameter specifies a group name. Process 
all modules in the first group with that group name. If the A option is also 
used, process all modules in all groups with that group name. 

With the C option, the name parameter specifies a group name prefix. 
Process all modules in all groups with that group name prefix from the 
pointer position to the end of the file. 

N- Do not list module header information on the librarian map. 

P- Punch all the modules specified. 

U- Without the G option, process the modules from the pointer position in the 
file up to and including the specified module; both the name and type 
parameters are needed to specify the module. With the G option, process all 
modules up to and including the first module group with the specified name. 

Note: Ifthe C and U options are used together, an error occurs. 


Positional Parameter 1 


input-lfn 
Specifies the logical file name of the file to be processed. 


If omitted, the job run file $Y$RUN is used. To list or punch all modules in a file, 
this parameter must be followed by a comma and all other parameters must be 
omitted. 
Positional Parameter 2 
S,M,0,L 
Specifies the type of modules to be processed as either program source (S), 
macro/jproc source (M), object (O), or load (L). 


If omitted, all modules with the specified name are processed. The type 
parameter is not valid when the G option is used. 
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Positional Parameter 3 


name 
Specifies the name of a particular module, module group (with G option), 
module name prefix (with C option), or group name prefix (with C and G 
options). It may contain up to eight characters. 


If omitted, all modules of the specified type from the pointer position to the end of 
the file are processed. If both the name and type parameters are omitted, all 
modules after the pointer position are processed. 


Examples 





COP.P D1,0,EXAMPLE1 
COP.D D2,S 

COP.DPU D3,S, EXAMPLES 
COP.CD D4, ,COB 

COP.GP D5, , EXAMPLES 
COP.D 6, 


auf WD 
ewe wt ce 


1. Punches the object module named EXAMPLE1 in file D1. 


2. Prints listings of all source modules from the pointer position to the end of 
file D2. 


3. Punches and prints listings of all modules from the pointer position in file 
D3 up to and including the source module named EXAMPLES. 


4. Prints listings of all modules with the name prefix COB from the pointer 
position to the end of file D4. 


5. Punches all modules in the next group named EXAMPLES in file D5. 


6. Prints listings of all modules from the pointer position to the end of file D6. 
Note that the trailing comma is required. 


3.3.18. Working with Module Groups 


364 


A module group is a consecutive series of modules in a file that have been placed 
between a beginning-of-group and an end-of-group record. These modules can be 
processed collectively using librarian control statements with the group option (G). 
Instructions for creating a module group are given in “Building Module Groups (BOG 
and EQG),” which follows in this section. Instructions for using the G option in 
librarian control statements are given in “Module Group Operations (G Option),” 
which also follows in this section. 


UP-8841 Rev. 4 














Librarian Control Statements 





Building Module Groups (BOG and EOG) 


Function 


UP-8841 Rev. 4 


The following steps are required to create a module group in a file: 

1. Write the beginning-of-group record to the file (BOG control statement). 

2. Add selected modules to the file. 

3. Write an end-of-group record to the file (EOG control statement). 

The BOG control statement must be used first to name the group and write a 
beginning-of-group record in the file. The group name may contain up to eight 
EBCDIC characters and need not be unique. This name will be independent of 
any module name in the file and will be used only to reference the entire group in 


subsequent group operations. 


After the BOG statement, other librarian control statements can be used to 
obtain modules from other files and add them to the file after the beginning-of- 


group record. The output file for these statements must be the same one used in 
the BOG statement for the group. 


After ali the modules have been added to the group, an EOG control statement is 
needed to write an end-of-group record in the file. This completes the group 
creation procedure. 

The following rules apply to the creation of module groups: 

¢ A module group is always added at the end of the output file. 

e = Asingle file can contain any number of groups. 

e Agroup can contain any number of modules of one or assorted types. 


¢ Groups may be nested (see B.2.1). 


e =A disk file cannot contain two modules with the same name and type 
combination, even if they are in different groups. 


Note: After a group is created, the beginning-of-group and end-of-group records 
only affect librarian processing when the G option is used. Thus, a 
librarian control statement that processes all modules of a certain type will 
apply to all modules of that type whether they are contained within a 
group or not. 
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group-name 
Specifies the name of the module group being created. It may contain up to 8 
characters. This name need not be unique. 
Positional Parameter 2 


lfn 
Specifies the logical file name of the file in which the group is being created. 


If omitted, the job run file $Y$RUN is used. 
Example 1 


4 18 16 





B0G  GROUP1,D1 
cop e,,,D1 
E0G  GROUP1,D1 


The BOG statement writes a group header record for the group named GROUP1 
in file D1. The COP statement between the BOG and EOG statement copies all 
modules in file DO to file D1 following the beginning-of-group record. The EOG 
statement writes an end-of-group record in file D1 after the last module is copied. 
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Example 2 


1 18 16 





EOD 
EOG GROUP2 


The BOG statement writes a group header record for the group named GROUP1 
in the job run file $Y$RUN. A source module on cards is placed between the ELE 
and EOD librarian control statements. This module is copied to $Y$RUN 
following the beginning-of-group record. The EOG statement writes an end-of- 
group record in $Y$RUN after the module is copied. 

Example 3 


See 3.6.3 for a sample librarian job control stream which builds groups. 


@ Module Group Operations (G Option) 
Once a module group has been created, the modules in it can be processed collectively 
by any of the librarian control statements which allow the group (G) option. Here is a 
list of those statements and a escription of how they process groups: 


e COP 


ACOP statement with an input file parameter, a name parameter, and an output 
file parameter copies module groups from the input file to the output file. 


ACOP statement with an input file parameter and a group name but no output 
file parameter lists (D option) or punches (P option) module groups. 


ACOP statement with an input file parameter, a group name, and only the G 
option resets the pointer past the next group with that group name. 


¢ DEL deletes all module groups. 
- @ RES resets the pointer to the next group with the specified group name. 


e REN renames groups with the specified group name. 
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The following syntax rules apply to these statements for group operations: 
¢ The statement must include the group (G) option. 

¢ The statement must include the name parameter. 

¢ The statement must not include a type parameter. 


Without the C or A option, the statement applies only to the next group in the input 
file with the group name specified by the name parameter. If the A option is used, all 
groups with that name are processed. If the C option is used, the name parameter 
specifies a group name prefix and the statement applies to all groups with the group 
name prefix from the pointer position to the end of the file. 


If the G and U options are used together, all modules from the pointer position up to 
and including the group specified by the name parameter are processed. 


The C and U options cannot be used together. 


Note: When the G option is not used, the beginning-of-group and end-of-group records 
do not affect librarian processing. Thus, a librarian control statement without a 
G option which applies to all modules with a certain name, for example, will 
affect all modules in the file with that name regardless of whether they are in a 
group or not. 





Examples 


1 10 16 





COP.G D1, ,GROUP1,D2 

COP.GD D3, ,GROUP2 

COP.GCD 04,,SRC,D5 

COP.GA D6, ,GROUP4,D7 

DEL.G D8, ,GROUPS 

DEL.GA D9, ,GROUP6 

DEL.GC D10, ,COB6 

REN.G D11,,GROUPA,GROUPB MERGED 9/9/88 
RES.G D12, ,GROUP8 


Oo ON OU FWD = 
eo 8 6« © 8 8 8 @ «@ 


1. Copies the next module group named GROUP! from file D1 to D2. 

2. Prints listings of all modules in the next group named GROUP? in file D3. 

3. Finds all module groups with the group name prefix SRC from the pointer to 
the end-of-file D4 and copies them to file D5. Also prints listings of all the 


modules copied. 


4. Finds all groups with the group name GROUP4 from the pointer to the end- 
of-file D6 and copies them to the end-of-file D7. 
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5. Deletes the next module group named GROUPS in file D8. 
6. Deletes all groups named GROUP6 following the pointer in file D9. 


7. Deletes all groups with the group name prefix COB6 following the pointer in 
file D10. 


8. Changes the name of the next module group named GROUPA in file D11 to 
GROUPB. Also changes the comment in the group header record to 
MERGED 9/9/88. 


9. Resets the pointer in file D12 to the next module group named GROUP8. 


3.3.19. Inserting Linkage Editor Control Statements 
in Object Modules (REPRO and EOD) 


Function 


The REPRO librarian control statement inserts or deletes embedded control 
statements in object modules. 


To perform insertions only, the librarian needs the following sequence of 
statements: 


REPRO | fn,module-name 


Any linkage editor control statements 
to be inserted after the header record 


EOD 


Any linkage editor control statements 
to be inserted after the transfer record 


EOD 


The REPRO librarian control statement identifies the file containing the object 
module to be modified and the name of the object module itself. This is followed by 
any linkage editor control statements to be inserted after the object module header 
record. The EOD librarian control statement indicates the end of these. Following the 
EOD statement are any linkage editor control statements to be inserted after the 
object module transfer record. These are followed by another EOD librarian control 
statement. Both EOD statements are always required with the REPRO statement, 
even if linkage editor control statements are not being added in both places. 


If the object module already contains a set of linkage editor control statements, the 
new ones are placed after the existing ones in the same order that they are supplied. 
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Any deletions required can be specified at the same time as insertions. This is done 
through the REPRO control statement, as follows: 


REPRO | fn,module-name,#deletions ,#deletions. 


Any linkage editor contro! statements 
to be inserted after the header record 


EOD 


Any linkage editor contro! statements 
to be inserted after the transfer record 


EOD 


In the REPRO control statement, the first #deletions specifies the number of records 
to be deleted after the object module header record; the second #deletions specifies the 
number of records to be deleted after the object module transfer record. Two EOD 
statements are still required following the REPRO statement even if no linkage editor 
control statements are being inserted in the module at the same time. 


The librarian always deletes the specified number of records from the end the existing 
records in that part of the module. For example, the following statements delete the 
last three linkage editor control statements after the header record and the last two 
linkage editor control statements after the transfer record: 


REPRO D1,MODA,3,2 
EOD 
EOD 


Deletions are always performed before insertions. Therefore, selected records can be 
deleted from between other records, by deleting them all and then adding some of 
them back again. This should be done with one REPRO statement, two EOD 
statements, and the linkage editor control statements being retained. 


The librarian makes the corrections by building a new version of the object module. 
After making all the corrections, the librarian deletes the original version and adds 
the new version at the end of the file. 


Note: The REPRO librarian control statement cannot be used for an object module on 
tape or data set label diskette. 


Format 





LABEL 





AOPERATIONA OPERAND 





unused REPRO[ .options] 





lfn nameL ,#deletionsI]{ ,#deletions] 
SYSRUN 
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Options 
D- Print a listing of the entire modified object module on the librarian map. 
N- Do not list module header information on the librarian map. 
P- Punch the entire module as modified. 
Positional Parameter 1 
Lfn 


Specifies the logical file name of the disk file containing the object module to 
be modified. 


If omitted, the job run file $Y$RUN is used. 
Positional Parameter 2 


Specifies the name of the object module to be modified. 
Positional Parameter 3 


#deletions 
@ This integer specifies the number of contro] statement records to be deleted 
from the end of the set of control statements which currently exist after the 
module header record. 


Positional Parameter 4 


deletions 
This integer specifies the number of control statement records to be deleted 
from the end of the set of control statements which currently exist after the 
module transfer record. 


Example 1 


Modify the object module named EXAMPLE in file Di as follows: Add the control 
statement records INCLUDE A and INCLUDE B at the end of any control 
statements following the module header record. List and punch the modified 
object module. 


i 18 16 





REPRO.DP 01, EXAMPLE 
INCLUDE A 

INCLUDE 8 

EOD 

EOD 
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Example 2 


Modify the object module named EXAMPLE in file D1 as follows: Add the linkage 
editor control statements INCLUDE A and INCLUDE B at the end of any 
linkage editor control statements following the module header record. Add the 
linkage editor control statement INCLUDE C at the end of any linkage editor 
control statements following the transfer record. 


1 18 16 





REPRO D1, EXAMPLE 
INCLUDE A 
INCLUDE B 

EOD 

INCLUDE C 

EOD 


Example 3 


Modify the object module named EXAMPLE in file D1 as follows: Add the linkage 
editor control statement LOADm X at the end of any linkage editor control 
statements following the module tramsfer record. List the modified object 
module. 


1 10 16 





REPRO.D D1, EXAMPLE 
EOD 

LOADm X 

EOD 


Example 4 


Modify the object module named EXAMPLE in file D1 as follows: Delete the last 
linkage editor control statement currently following the object module header 
record and then add the source record INCLUDE A after the header record. Also, 
delete the last three linkage editor control statements currently following the 
object module transfer record and then add the source record RES X‘1000’ after 
the transfer record. List the modified object module. 


1 18 16 





REPRO.D D1,EXAMPLE,1,3 
INCLUDE A 

EOD 

RES X'1080! 

EOD 
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Example 5 


Modify the object module named EXAMPLE in file D1 as follows: Add the linkage 
editor control statement INCLUDE A at the end of any linkage editor control 
statements currently following the module header record. Delete the last three 
linkage editor control statements currently following the object module transfer 
record and then add the linkage editor contro] statement record INCLUDE B 
after the transfer record. List and punch the modified object module. 


1 18 16 





REPRO.DP D1,EXAMPLE, ,3 
INCLUDE A 

EOD 

INCLUDE B 

EOD 


3.3.20. Saving Librarian Control Statements on Disk or Diskette 


A series of librarian contro] statements can be saved on disk or format label diskette 
and then accessed when needed by a librarian job. This eliminates the need for the 
user to keep rewriting frequently used librarian routines. Modules containing just 
librarian control statements are considered source modules. Instructions for creating 
and saving these modules are given in "Writing and Saving the Control Statements," 
following in this section. Once the control statements are saved, they can be accessed 
by other librarian jobs using the ESC statement described in "Using Saved Librarian 
Control Statements,” also following in this section. 


Note: This procedure is for saving only librarian control statements. The example in 
3.6.4 explains how to save a complete librarian job control stream. 


Writing and Saving the Control Statements 


One way to create and save a series of librarian control statements on disk is to use 
the general editor (EDT) at a workstation. For instructions on using the general 
editor, see the General Editor Operaiing Guide (UP-9976). For example, the following 
librarian control statements can be written in the editor work space as shown (the 
numbers on the left are work space line numbers): 


1.0000 COP D1, S, COBOL4 D2 
2.0000 LST 2 
3.@@@0QWRITE MO=LIBTEST, TYPE=S, FIL=SRCFIL 


Lines 1 and 2 are the librarian control statements being saved. The general editor 
@WRITE command (line 3) saves the statements in the module named LIBTEST in 
the diskette file named SRCFIL. The module type must be S for source. 
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The series of librarian control statements can also be punched on cards and copied to 
diskette using the librarian. The following is a sample librarian job control stream to 


do this: 


// JOB SAVE 


// OVC 28 // LFD PRNTR 
// DVC 138 // VOL PUBRES 
// LBL SRCOFIL f/f LFD SRCFIL 


// EXEC LIBS 


% 
FIL 
ELE 
cop 
LST 
£00 

f* 

/% 

Sf FIN 


D1=SRCFIL 

D1,S,LIBTEST 

D1,S,COBOL4 ,D2 Librarian control statements being saved 
d2 


In this example, the file SRCFIL has already been allocated on the format label 
diskette volume PUBRES. The ELE statement identifies the diskette file D1, or 
SRCFIL, where the librarian control statements are to be saved. It also creates and 
names the module LIBTEST to contain them. The module type must be S, for source. 
The EOD librarian control statement is associated with the ELE statement to identify 
the end of the statements being saved. 


Using Saved Librarian Control Statements (ESC) 


Function 


After a series of librarian control statements have been saved on disk or diskette, 
they can be called by other librarian jobs through the use of the ESC librarian 
control statement. This statement accesses the source module containing the 
control statements and inserts them in the librarian job control stream where 
they are to be used. The following rules apply: 


e The file containing the source module must be declared in a device 
assignment set, just like any other disk or format label diskette file. 


° The ESC statement may be one of any number of statements used in a 
librarian job. 


* A librarian job may contain more than one ESC statement. 
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e For each ESC statement used in a librarian job, the librarian requires 7400 
(hexadecimal) bytes of main storage space to run. This must be specified in 
the // JOB control statement, as follows: 


// JOB MYJOB,, , 7488 


¢ The ESC statement itself must be placed between the /$ and the /* job 
control statements. 


All statements obtained from the a source module via an ESC statement are 
listed on the librarian map with *ESC* in the control field. 


Format 

LABEL AOPERATIONA OPERAND 

unused ESC filename, LD,modulename 
Options 

None 


Positional Parameter 1 
filename 
Specifies the name of the file containing the source module. This must match 
the name used in the // LFD job control statement for that file. 


Positional Parameter 2 


LD 
Indicates the control stream is in a librarian source module. 


Positional Parameter 3 


modul ename 
Specifies the name of the librarian source module to be processed. 


Example: 
The following librarian control statements have already been saved in a source 
module named LIBTEST in the file named SRCFIL on the diskette volume 
PUBRES: 


cop D1,S,COBOL4,D2 
Lst D2 
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The following librarian job uses these saved librarian control statements: 





1. | s/ JOB ESCRUN,, ,7400 

2. | // DVC 2@ //LFD PRNTR 

3. | // DVC 138 // VOL PUBRES 
4. | // LBL HAMMER // LFD HAM 

5. | // DVC 130 // VOL PUBRES 

6. | // LBL SRCFIL // LFD SRC 

7. | // EXEC LIBS 

8. | /s 

9. FIL D1=HAM,D2=SRC 
10. ESC SRC,LD,LIBTEST 
11.) /* 

12.}| /& 


1. JOB statement specifying additional bytes of main storage needed. 
2. Device assignment set for a printer to produce a librarian map. 
3 and 4. 


Device assignment set for file containing the diskette file HAMMER, 
which contains the module COBOL4. 





5 and 6. 
Device assignment set for the diskette file SRCFIL. This file contains 
the source module LIBTEST to be accessed by the ESC statement. It is 
also the file where the module COBOL4 is to be copied. 

7. Initiates execution of librarian. 

8. Identifies the start of the librarian control statements. 

9. Declares the files to be processed by the librarian job. 

10. Initiates ESC processing of the saved librarian control statements. 


11. Indicates the end of the librarian control statements. 


12. Indicates end of job. 
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3.4. MIRAM Librarian Control Statement Descriptions 


This section contains detailed descriptions of the MIRAM librarian control 
statements. Each statement description includes the statement function, syntax, and 
syntax examples. Information on the job control required to use the MIRAM librarian 
is described in 2.7. A sample job control stream in 2.7.6 illustrates how the control 
statements work together. 


Table 3-2 contains a summary of the functions associated with each MIRAM librarian 
control statement. Each statement is described in detail in the subsection indicated. 


Table 3-2. MIRAM Librarian Control Statement Summary 


Changes the name or comment in a module header. 

Copies modules or files. 

Deletes modules from files. 
i ile di : 





Statement Description 







Assigns logical file names 
Prints a module listing or file directory. 


3.4.1. Assigning Logical File Names (FIL) 


Function 


The FIL librarian control statement equates each disk, tape, and diskette file 
name used in an // LFD job control statement to a file with a logical file name. A 
logical file name for a MIRAM file must be in the range FO through F29. The 
logical file name is then used exclusively to reference each file in subsequent 
librarian control statements. 


Up to 30 files can be declared in a single FIL statement. A comma, no spaces, is 
used to separate successive file declarations in a single FIL statement. Disk, tape, 
and diskette files may be declared in the same FIL statement. 


The FIL statement only assigns logical file names to files; it does not open the 


files. A file is only opened when its logical file name is used in a subsequent 
librarian contro] statement. 
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Up to six files can be open at one time. If more files are used, only the latest six 
remain open. Otherwise, a file remains open until the job step is completed or its 
logical file name is assigned to another file by another FIL librarian control 
statement in the job step. Therefore, if it is not necessary to have all the files 
open at one time during a librarian job step, it is a good idea to reuse the logical 
file names in another FIL librarian control statement. This way, the files will be 
closed when they are no longer needed. 


Note: Because librarian control statements do not reference files by their actual 
names, the same set of librarian control statements can be used 
interchangeably to perform the same operations on any files; only / | LFD, 
// LBL, and FIL statements must be changed to identify the new files. 







Format 
AOPERATIONA OPERAND 
unused Fn=filename-1[,...,fn=filename-nJ 
Options 
None 


Keyword Parameter 





Fn=filename 
Equates a MIRAM filename to a logical file name. The number n can range 
from 0 to 29. 


The filename must match the file name used in the // LFD job control statement 
for the file, the system file name, or the job run file name $Y$RUN. 


Example 


1 10 16 





// 3OB FLTST 

// DVC 20 // LFD PRNTR 

// OVC 50 // VOL 060012 // LBL MINE // LFD MY 
// DVC 5@ = // VOL D@@020 // LBL YOUR // LFD YR 
// OVC 5@ // VOL DO@O12 // LBL HIS // LFD HS 
// DVC 5@ // VOL DO@@20 // LBL HERS // LFD HR 
// EXEC MLIB 


/$ 
FIL FQ=MY,F1=YR 
cop F@,,,F1 
FIL FQ=HS,F1=HR 
cop F1,,,F1 

/* 

/& 
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The first FIL statement assigns the logical file name FO to the disk file MINE 
and the logical file name F1 to the file YOUR. The first COP statement copies all 
modules from the file MINE to the file YOUR. The second FIL statement closes 
the file MINE and reuses the logical file name FO by assigning it to the file HIS. 
The second FIL statement also closes the file YOUR and reuses the logical file 
name F1 by assigning it to the file HERS. The second COP statement then copies 
all modules from the file HIS to the file HERS. 


3.4.2. Copying Modules and Files (COP) 
Function 


The COP librarian control statement is used to copy modules from one file to 
another. Options and parameters used in the COP statement determine which 
modules are copied. Deleted modules are never copied. 


Modules are obtained from an input file and copied to the output file. When the 
output file already contains a module of the same name and type as the one being 
copied, the existing module is deleted from the output file and the new module is 
added. 


Note: The SETREL and COPYREL canned job control streams are available to 
backup or copy files from a system release volume. See Appendix A for 


more information. 
Format 
LABEL | AOPERATIONA OPERAND 
unused COP[ .options} input-t fn, [module- type}, [name] output -{ fn 
Options 
C - Process only modules with the name prefix specified in the name parameter. 
Positional Parameter 1 
input - Ufn 


Specifies the logical file name of the file containing the modules to be copied. 
Positional Parameter 2 


module- type 
Specifies the type of module being copied, as foliows: 


F - Type F screen format modules 


FC - Type FC screen format modules 
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HELP - Help screen modules 

J - Saved run library modules 

MENU - Menu modules 
If omitted, all modules with the specified name or name prefix (with C option) are 
copied. If both the name and type parameters are omitted, all modules in the file 
are copied. 
When the file contains only screen format modules, the type parameter may be 
omitted to copy both the type F and type FC modules with the same name using 
one COP statement. When the file contains other types of modules, two COP 
statements are needed to copy two screen format modules with the same name. 


Positional Parameter 3 


name 
Specifies a module name or a module prefix (with C option). 


If omitted, all modules of the specified type are copied. If both the name and type 
parameters are omitted, all modules in the file are copied. 


Positional Parameter 4 





output-Lfn 
Specifies the logical file name of the file to which the modules are to copied. 





Examples 
1 1016 
1. cop F@,,,Fi2 
2. COP -F1,F,EXAMPLE2, F2 


cop F1,FC,EXAMPLE2,F2 
3 cop F3,,EXAMPLE3,F4 
4. COP F5,J,EXAMPLE4, F6 
5. COP.C F7,,EXA,F8 
6 COP.C F9,J,EXA,F10 


1. Copies all modules from file FO to file F12. 


2. This pair of statements copies the screen format modules named 
EXAMPLE2 from file F1 to file F2. The first copies the type F module; the 
second copies the type FC module. If file F1 contains only screen format 
modules, only one COP statement is needed to copy both the type F and type 
FC modules with the name EXAMPLE2. This statement must specify the 
name but omit the type (see Example 3 below). , 


3. Copies all modules named EXAMPLES from file F3 to F4. 
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4. Copies the saved run library module named EXAMPLE4 from file F5 to F6. 
5. Copies all modules with the name prefix EXA from file F7 to F8. 


6. a all saved run library modules with the prefix EXA from file F9 to 
3.4.3. Printing Listings of Modules and Directories (PRT) 
Function 
The PRT librarian control statement is used to do the following: 
¢ Print listir.gs of modules 
¢ Print a file directory 
Note: The LISTRES and MODLST canned job control streams are available to 


print listings and directories of files on a system release volume. See 3.5.1 
and 3.5.3 for more information. 


Format 
& LABEL AOPERATIONA OPERAND 
unused PRTL .options] Lfn[ ,module-typel][,name] 
Options 


C- Process only modules with the 11ame prefix specified in the name parameter. 


D- Print file directory records only. If used, the name parameter must be 
omitted. If not used, print module listings. 


Positional Parameter 1 


lfn 
Specifies the logical file name of the file to be processed. 


Positional Parameter 2 


module - type 
Specifies the type of module to be processed, as follows: 


F - Type F screen format modules 
FC - Type FC screen format modules 


@ HELP - Help screen modules 
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J - Saved run library modules 
MENU - Menu modules 


If the type is omitted and the D option is used, all records in the file directory are 
printed. If both the type and D option are used, only module header records of 
that type are printed. If both the name and type parameters are omitted, all 
modules in the file are listed. 


When the file contains only screen format modules, the type parameter may be 
omitted to process both the type F and type FC modules with the specified name. 
When the file contains other types of modules, two PRT statements are needed to 
process the modules of each type. 


Positional Parameter 3 


name 
Specifies a module name or a module name prefix (with C option). 


If omitted, all modules of the specified type or all modules with the specified 
name prefix (with C option) are listed. If both the C option and the type 
parameter are used, all modules of the specified type with that name prefix are 
listed. If both the name and type parameters are omitted, all modules in the file 
are listed. 





This parameter must be omitted when the D option is used. 





Examples 
1 18 16 
1. PRT FQ 
2. PRT F2, F, EXAMPLE2 
PRT F2,FC,EXAMPLE2 
3. PRT 3, ,EXAMPLE3 
4. PRT.C F4,J,EXA 
5. PRT.C F5,,EXA 
6. PRT.D FS 
7. PRT.D F7,MENU 


1. Prints listings of all modules in file FO. 


2. This pair of statements prints listings of the screen format modules named 
EXAMPLE? in file F2. The first lists the type F module; the second lists the 
type FC module. If file F2 contains only screen format modules, only one 
PRT statement is needed to list both the type F and type FC modules named 
EXAMPLE2. This statement must specify the name, but omit the type (see 
Example 3 below). ; 


3. . Prints listings of all modules of any type named EXAMPLES in file F3. 
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4. Prints listings of all saved run library modules with the name prefix EXA in 
file F4. 


5. Prints listings of all modules of any type with the name prefix EXA in 
file F5. 


6. Prints all directory records in file F6. 


7. Prints header records for all menu modules in file F7. 


3.4.4. Deleting Modules from Files (DEL) 
Function 
The DEL librarian control statement is used to delete one or more modules from 
a file. The use of options and parameters in the DEL control statement allow the 
following variations: 
¢ Delete all modules in a file. 
* Delete the module with the specified name and type. 
¢ Delete all modules with a specified name. 


¢ Delete all modules with a specified name prefix. 


¢ Delete all modules of a specified type. 


Format 

LABEL AOPERATIONA OPERAND 

unused | DEL[.options] l fn ,module-type}[ ,name] 
Options 


C- Process only modules with the name prefix specified in the name parameter. 
Positional Parameter 1 
lfn 


Specifies the logical file name of the file containing the modules to be 
deleted. 
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Positional Parameter 2 


module- type 
Specifies the type of module being deleted, as follows: 


F - Type F screen format modules 

FC - Type FC screen format modules 

HELP - Help screen modules 

J - Saved run library modules 

MENU - Menu modules 
If omitted, all modules with the specified name or name prefix (with C option) are 
deleted. If both the name and type parameters are omitted, all modules in the file 
are deleted. 
When the file contains only screen format modules, the type parameter may be 
omitted to delete both the type F and type FC modules with the same name. 
When the file contains other types of modules, two DEL statements are needed to 
delete the modules of each type. 


Positional Parameter 3 





name 
Specifies a module name or a module name prefix (with C option). 


If omitted, all modules of the specified type are deleted. If both the name and 
type parameters are omitted, all modules in the file are deleted. 


Examples 


1 10 16 





1. DEL Fe 

2. DEL F1,F,EXAMPLE2 
DEL F1,FC, EXAMPLE2 

3. DEL F3,,EXAMPLE3 

4. DEL F4,J, EXAMPLES 

5 DEL.C F5,,EXA 

6 DEL.C F6,MENU,EXA 


1. Deletes all modules in file FO. 


2. This pair of statements deletes the screen format modules named 
EXAMPLE2 from file F1. The first deletes the type F module; the second 
deletes the type FC module. If file F1 contains only screen format modules, 
only one DEL statement is needed to delete both the type F and type FC 
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modules named EXAMPLE2. This statement must specify the module name 
but omit the type (see example 3 below). 


3. Deletes all modules named EXAMPLES from file F3. 
4. Deletes the saved run module named EXAMPLE4 from file F4. 
5. Deletes all modules with the name prefix EXA from file F5. 


6. Deletes all menu modules with the prefix EXA from file F6. 


3.4.5. Changing Module Names and Comments (CHG) 
Function 
The CHG librarian control statement is used to change the name of an existing 
module or change comments in a module header record. Each CHG statement can 


make only one change, either a name change or a comment change, for one 
module. 


If a module name is being changed and the file already contains a module of the 
specified type and the new name, an error message is printed on the librarian 
map and no change is made. 


@ A new comment replaces any exisiting comment in its entirety. 


Format 







LABEL AOPERATIONA OPERAND 





CHG[ options] acral eas } 


C, ‘comment! 
Options 
None 
Positional Parameter 1 
lfn 
Specifies the logical file name of the file containing the module being 
processed. 


Positional Parameter 2 


module- type 
Specifies the type of module being processed, as follows: 


F - Type F screen format modules 
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FC - Type FC screen format modules 
HELP - Help screen modules 
J - Saved run library modules 
MENU - Menu modules 

Positional Parameter 3 


old-name 
Specifies the name of the module being processed. 


Positional Parameter 4 


N,C 
Identifies the kind of change to be made. N specifies a module name change; 
C specifies a comment change in the module header record. If N is used, a 
new-name must be supplied in positional parameter 5. If C is used, a 
comment must be supplied in positional parameter 5. 


Positional Parameter 5 


new-name 
Specifies a new module name containing up to eight letters or digits. The 
first character must be a letter. If used, N must be used in positional 
parameter 4. 


‘comment! 
Specifies a new comment of up to 30 characters to be inserted in the module 
header record. The comment must be enclosed in single quotation marks. If 
used, C must be used in positional parameter 4. 





Examples 
1 10 16 
1. CHG FO, F, VERSION1,N, VERSION2 
CHG FQ, FC, VERSION1,N, VERSION2 
ee CHG F2,J,RUN6,N,RUN7 
CHG F2,J,RUN7,C, "REVISED BY CGM! 
3. CHG = F3, J, CHS@@1,C, "UPDATED 2/16/82! 


1. This pair of statements change the name of both screen format modules 
(type F and type FC) from VERSION1 to VERSION? in file FO. 


2. The first statement changes the name of the saved run library module in file 


F2 from RUN6 to RUN7. The second statement changes the comment in the 
header record for that same module to ‘REVISED BY CGM’. 
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3. Changes the comment in the header record for the saved run library module 
named CHS001 to ‘UPDATED 2/16/82’. 


3.5. Canned Librarian Job Control Streams 


This section describes the canned librarian job control streams provided in the system 
library. The job control streams reside in the system job control stream file $Y$JCS; 
the associated load modules which are actually run reside in the system load file 
$Y$LOD. 


Each job control stream is executed by keying in its associated RV command at the 
system console. Table 3-3 lists each job name and the function it performs. Each 
function is described in detail in the section indicated. These canned librarian job 
control streams are summarized along with other available canned job control streams 
in Appendix A. 


Table 3-3. Canned Librarian Job Control Streams 









Prints a directory of modules in a release volume. 
Prints a disk display of any disk file directory. 


Prints listings of the modules in the system 
Rbraries of a release volume 
Compresses aii files in a release volume and 
prints updated directories. 


3.5.1. Printing a Directory of a Release Volume (LISTRES) 
Function 

LISTRES prints a directory of all modules in a release volume or all modules in a 

particular file in a release volume. See Table 3-4 for a list of the modules 

included. 

Note: LISTRES can list a directory only for the SYSRES volume, a release 
volume, or a backup copy of a release volume because it assumes that 
certain files exist in the volume being processed. If the volume specified is 
not a release volume and these files are not present, errors may occur. 


Command Format 


RV LISTRES[,(,F=filenamel[,V=vsn}} 
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F Keyword Parameter 


F=f i lename 
If used, a directory of all modules in the specified system file is listed. If 
omitted, a directory of the entire release volume specified is listed. Table 3-4 
lists the abbreviated filenames to be use for the filename parameter. More 
than one filename may be specified. The filenames must be separated by 
commas and enclosed in parentheses (see Examples 2 and 3). 


V Keyword Parameter 
V=vsn 
Specifies the volume serial number of the release volume to be processed. If 


omitted, the active system-resident pack is assumed. 


Examples 





RV LISTRES, ,F=OBJ, V=REL120 


1 
2.| RV LISTRES, ,F=(LOD, JCS, SRC) 

3.| RV LISTRES, ,F=(HELP,MSG) , V=REL120 
4.| RV LISTRES, ,V=REL12@ 

5.| RV LISTRES 


1. Prints directory of all modules in the file $Y$OBJ on release volume 
REL120. 





2. Prints directory of all modules in the files $Y$LOD, $Y$JCS, and $Y$SRC on 
the active system-resident pack. 


3. Prints directory of all modules in the files $Y$HELP and $Y$MSG on release 
volume REL120. 


4. Prints a directory of all modules in all files in release volume REL120. 


5. Prints a directory of all modules in all files on the active system-resident 
pack. 
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Table 3-4. Files Processed by LISTRES and PACKRES 


F=filename Filename File content 
LOD System load modules 
_ son dea 
MAC System macro modules 
SRC System source modules 
JCS System job control streams 
SMC System maintenance correction file 
HELP System help screens 
SHR Information on active shared code modules 
SDF System definition file indicating microcode level of all 
workstations 
@ NP Installation verification programs 
SCLOD System shared code load modules 
MIC Microcode for loadable components 
SAVE System saved job run streams 
DLF SYSDIALOG Dialog screens for job control and system generation 
FMT System screen format modules 
MSG System messages 
SGSJCS SYSGEN job contro! streams 
SGSLOD SYSGEN load modules 
SGSOBJ } soso SYSGEN object modules 
SGSMAC SYSGEN macro modules 
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3.5.2. Printing a Disk Display of a Disk File Directory (DRDP) 
Function 
DRDP prints a sequential disk display of any disk file directory. 
Command Format 
RV DROP, , V=vsn, L=file- identifier 
V Keyword Parameter 
V=vsn 
Specifies the volume serial number of the volume containing the file to be 
processed. 
L Keyword Parameter 
L=file-identifier 
Specifies the file-identifier for that file, as recorded in the volume table of 
contents. 


Examples 


1.] RV ORDP, , V=DSK001,L=RTCHG 
2.| RV DROP, ,V=000022, L=CUST88 


1. Prints a disk display of the directory for the file RTCHG on disk volume 
DSKO001. 





2. Prints a disk display of the directory for the file CUST88 on disk volume 
D00022. 


Note: The maximum length for the file-identifier is 11 characters. To process a 
file with a file-identifier of more than 11 characters, use the following job 
control stream: 


1 18 16 





// OVC 28 // LFD PRNIR 
// ove =—58 J/ NOL vsn // LBL file-identifier 
4/ LFD LUSDTFI 


// EXEC SULBD 
// PARAM file-identifier 


1/ FIN Required only if job is run using punched cards. 
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e 3.5.3. Printing Listings of Modules in the System Libraries of a Release 
Volume (MODLST) 


Function 


MODLST prints listings of all modules and macros in the five system libraries 
$Y$SRC, $Y$OBJ, $Y$LOD, $Y$JCS, and $Y$MAC. Each module and macro is 
listed in alphanumeric sequence along with a description of its function and size. 


Note: MODLST can only print listings of modules in the SYSRES volume, a 
release volume, or a backup copy of a release volume because it assumes 
that certain release files exist in the volume being processed. If the volume 
specified is not a release volume and these files are not present, errors may 
occur. To print listings of modules in any other volumes, use the SAT or 
MIRAM librarian. 


Command Format 
RV MODLST[, , VSN=vsn] 
VSN Keyword Parameter 
VSN=vsn | : 
Specifies the volume serial number for a disk where a 30-cylinder workspace 
& is to be allocated for processing MODLST. If not specified, the disk 
containing the job run file $Y$RUN is used. 


Examples 


1.] RV MODLST, , VSN=WRKDSK 

2.| RV MODLST 

1. Prints listings of all modules in $Y$SRC, $Y$OBJ, $Y$LOD, $Y$JCS, and 
$Y$MAC on the active system-resident pack. A work space is allocated on 


the disk WRKDSK. 


2. Prints listings of all modules in $Y$SRC, $Y$OBJ, $Y$LOD, $Y$JCS, and 
$Y$MAC on the active system-resident pack. 
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3.5.4. Compressing a Release Volume and Printing Update Directories 
(PACKRES) 


Function 


PACKRES compresses and prints updated directories of the module header 
information for files in a release volume. The files are listed in Table 3-4. 


Notes: 


1. Before PACKRES is run, the system must be loaded using the IPL procedure 
described in the Operations Guide (UP-8859). 


2. PACKRES can only compress files in the SYSRES volume, a release volume, 
or a backup copy of a release volume because it assumes that certain release 
files exist in the volume being processed. If the volume specified is not a 
release volume and these files are not present, errors may occur. To compress 
files in any other volumes, run a librarian job using the SAT librarian PAC 
control statement or the MIRAM librarian COP control statement. 


3. PACKRES must be run only in an idle system. Use the MI DA command at 
the system console to ensure that no other jobs or symbionts are active. If 
interactive services is still active, it must be shut down. Any users that are still 
logged on must be logged off and then a 00 IS SHUTDOWN command must 
be executed to remove interactive services from the system. 


4. The system must be re-IPLed after PACKRES completes to ensure that all 
system file pointers are reset. 


Command Format 
RV PACKRES[,[ ,F=filename][ ,V=vsn}] 
F Keyword Parameter 
F=filename 
If used, all modules in the specified system file are processed. If omitted, all 
files in the the specified release volume are processed. Table 3-4 lists the 
abbreviated filenames for the filename parameter. More than one filename 
may be specified. The filenames must be separated by commas and enclosed 
in parentheses (see Examples 2 and 3 under “Examples”). 
V Keyword Parameter 
V=vsn 


Specifies the volume serial number of the release volume to be processed. If 
omitted, the active system-resident pack is assumed. 
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RV PACKRES, ,F=0B8J , V=REL 120 
RV PACKRES, ,F=(LOD, JCS, SRC) 


RV PACKRES, , V=REL120 


1 
2. 
3. | RV PACKRES, ,F=(HELP, FMT), V=REL120 
4. 
5. | RV PACKRES 


1. Compresses the file $Y$OBJ on release volume REL120. 


2. Compresses the files $Y$LOD, $Y$JCS, and $Y$SRC on the active 
system-resident pack. 


3. Compresses the files $Y$HELP and $Y$FMT on release volume REL120. 
4. Compresses all files in release volume REL120. 


5. Compresses all files on the active system-resident pack. 


3.6. SAT Librarian Programming Examples 


@ . 3.6.1. Rearranging Modules in a Disk File 


This job rearranges modules in a disk file. It copies modules from the original file into 
a new file in the new sequence as shown in the following listing. The names such as 
MODAI and MODA7 are the names of the first and last modules in each series of 
consecutive modules that are copied with each COP statement. After all the modules 
are copied to the new file, the original file is scratched and the new file is renamed as 
the original. Figure 3-5 illustrates the librarian map for this job. 


Original Fite New Fie 
{ORIGINAL} (HOLD) 
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// SOB SHUFFLE 

// OVC 20 // LFD PRNTR 

// DVC 5@ // VOL De8410 
// LBL ORIGINAL //-LFD RG 
// OVC 5@ // VOL 0004128 
// EXT ST,,1,BLK, (256,4800) 
// LBL HOLD // LFD-HD 

// EXEC LIBS 


/$ 
FIL D1=RG,D2=HD 
cop D1 
RES 1,S,MODD1 
COP.U D1,$,MODD6, D2 
RES 01,S,MODA1 
COP.U D1,0,MODA7, D2 
RES 1,S,MODC1 
COP.U D1,L,MODC8,D2 
RES 1,S,MODB1 
COP.U D1,L,MODB8, D2 
RES 01,S,MODE1 
COP.U D1,S,MODE4 , D2 
COP 02 

/* 

// SKIP END, 11111111 

// SCR RG 

// REN HD, ORIGINAL 

//END NOP 

/& 

Identifies the job. 

Assigns a printer to the job. 


Identifies the logical unit number 50 for the disk volume D00410, which 
contains the original file. 


Declares the file name ORIGINAL and the logical file descriptor RG for the 
original file. 


Identifies the logical unit number 50 for the disk volume D00410 to be used 
for the new file. 


Allocates file space for the new file. 


Declares the file name HOLD and the logical file descriptor HD for the new 
file. 
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Initiates execution of the librarian. 

Indicates the start of the librarian control statements. 

Assigns a type code and a logical file number to the files in the job. Thus, in 
the control statements that follow, D1 refers to ORIGINAL and D2 refers to 
HOLD. 


Prints a sequential list of the modules in the file ORIGINAL before the 
modules are rearranged. 


12. through 21. 


22. 


23. 


Copy modules from the file ORIGINAL to the file HOLD, moving a series of 
consecutive modules at a time. Each RES statement sets the pointer in the 
file ORIGINAL to the first module in the series. Then a COP statement 
copies all modules from the pointer to the module named in the COP 
statement. 


Prints a sequential list of the modules in the file HOLD. 


Identifies the end of the librarian control statements. 


24. and 27. 


25. 
26. 


28. 


Skip the scratch and rename operation if any errors occur in the job. 
Scratches the file ORIGINAL. 
Renames the file HOLD to ORIGINAL. 


Indicates the end of job. 


Note: To save both the original file and the new file, omit lines 24 


through 27. 
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3.6.2. Sorting Modules into Separate Files by Type 


This job sorts modules from one file into separate files for each module type. This job 
was run interactively, so the files for each module type were allocated with an 
interactive services ALLOCATE command before the job was run. Figure 3-6 
illustrates the librarian map for this job. Note that the last COP statement caused an 
error because there were no macro/jproc source modules in the original file. However, 
the job terminated normally. 


Job Control Stream 





1. | // JOB TYPSRT 

2. | // DVC 20 // LFD PRNTR 

3. | // DvC 5@ // VOL 000410 

4. | // UBL ORIGINAL // LFD RG 

5. | // DVC 5@ // VOL 000410 

6. | // LBL ALLSRC // LFD SC 

7. | // DV 5@ // VOL 000410 

8. | // LBL ALLOBJ // LFD 08 

9. | // DVC 50 // VOL 000410 

10.| // LBL ALLLOD // LFD LD 

11.1 // DVC 50 // VOL DQG410 

12.1 // LBL ALLMAC // LFO MC 

13.| // EXEC LIBS 

14.1 /$ 

5. FIL D1=RG,D2=SC,03=08 ,D4=LD, D5=MC 

16. cop 1 

17. cop D1,S, ,D2 

18. CoP 1,0, ,D3 

19. CoP D1,L,,D4 

20. COP D1,M,,D5 

21.4 /* 

22.) /& 

1. Identifies the job. 

2. Assigns a printer to the job. 

3. Identifies the logical unit number 50 for the disk volume D00410 that 
contains the original file. 

4. Declares the file ORIGINAL and the logical file descriptor RG for the 
original file. 

5. through 12. 
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Are device assignment statements for the files for each module type. All are 
on the disk volume D00410 with the logical unit number 50. The files are 
named ALLSRC, ALLOBJ, ALLLOD, and ALLMAC and are assigned the 
logical file descriptors SC, OB, LD, and MC, respectively. 
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13. 


14, 


15. 


16. 


17. 


18. 


19. 


20. 


21. 


22. 
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Initiates execution of the librarian. 

Indicates the start of the librarian control statements. 

Assigns a type code and logical file number to the five files used in the job. 
Thus, in the control statements that follow, D1 refers to ORIGINAL, D2 to 
ALLSCR, D3 to ALLOBJ, D4 to ALLLOD, and D5 to ALLMAC. 

Prints a table of contents of all modules in the file ORIGINAL. 


Copies all source modules from the file ORIGINAL to the file ALLSCR and 
prints a list of all of the modules copied. 


Copies all object modules from the file ORIGINAL to the file ALLOBJ and 
prints a list of all of the modules copied. 


Copies all load modules from the file ORIGINAL to the file ALLLOD and 
prints a list of all of the modules copied. 


Copies all macro/jproc modules from the file ORIGINAL to the file ALLMAC 
and prints a list of all of the modules copied. 


Indicates the end of the librarian control statements. 


Indicates the end of job. 
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Figure 3-6. Librarian Map for Sorting Modules by Type (Part 1 of 3) 


TYPE OaTe 


TIME 


COMMENTS 


01=RG,D2=SC ,03=08,D04=L0,05=HC 


Ts 000410, 
Is 000410, 
Ts 000410, 
Is 000430, 
TS 000410, 
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tFo 
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LFO 


Is 
Ts 
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PAGE # 00N2 
BLOCK REC NAME TYPE DATE TIME COMMENTS 


TABLE OF CONTENTS 


SOURCE “0001 60/08/08 16634 
SouRCE mODD2 80/08/08 16.35 
SOURCE 40003 80/08/08 16.37 
SOURCE #0004 80/08/08 16.39 
SOURCE moo0s 80/08/08 16-41 
SOURCE MOOD6 80/08/08 16.43 
SOURCE MODAL 81/04/27 09.14 
SOURCE MODA2 81/08/27 09.22 
LOAD 400A 3000 81/05/06 11.16 
Load 40044000 81/05/08 10.44 
SOURCE 4004S 81/05/08 11.06 
SOURCE MODA6 81/05/12 13.45 
OBJECT MODAT aisassi2 13.48 
SOURCE moocl 81/08/14 13.35 
SOURCE mO0C2 81/08/21 10.51 
source MOonCcs 31/08/24 10-43 
SOURCE 400C4% 61/08/24 10.47 
Load moocsa000 81/08/24 10.84% 
SOURCE MODC6 81/09/01 19-28 
LOAD 400C 7990 81/09/11 a8.30 
Load moocsGa0 09/00700 00.03 
SOURCE “00861 81708712 13.59 
SOURCE M0082 81/06/01 12.33 
LOAD 400B 3000 81/06/01 12.50 
SOURCE MODB4 81/06/05 12.45 
source MOOBS 81/06/29 12-38 
LOAD 40086000 81/07/06 14.52 
LOoaD 40087000 81/07/10 14.14 
Load "008 80u0 81/08/14 13.31 
source MODE) 80/08/08 16244 
SOURCE MOODE2 80/08/08 16.45 
SOURCE MODE 3 80/08/08 16.45 
SOURCE MODES 80/08/08 16047 


BLOCKS REMAINING OIRECTORY ONCOOO PRIME 90000 THIRD GO000N UNUSED NOND0Nn0 


oo COMMAND coscocsee cop D1,S9202 

goo0ag1 005 “oo01 SOR 80/08/08 16.34 
Qooo0s 052 Mo002 sor 80/08/08 16.35 
000005 067 "0003 sor 80/08/08 16.37 
000007 00S “ODDS Sor 80/08/08 16.39 
oooce0s aos "o005 sor 80/08/08 16.41 
Qgacoos i171 MODD6 sor 80/08/08 16.43 
@00009 138 mooal sor 61/04/27 G9.14 
Goooi8 033 MODA2 Sor 81/08/27 09.22 





Figure 3-6. Librarian Map for Sorting Modules by Type (Part 2 of 3) 
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BLOCK REC 
goaois 179 
g000i8 aT2 
000019 O71 
a00621 080 
g00022 O74 
QG0026 095 
gonag27? d62 
000029 ans 
00003: 135 
gooco4s 3005 
g000%6 O91 
agao#s aos 
Q000489 135 
000050 1:30 
gogos2 aos 


oe COMMAND ccocvcece 
gqaool 9005 


oe COMMAND coccsecces 


googgi aos 
gogo04 177 
g00005 421 
oggggs 176 
000016 164 
090022 u57 
000030 G21 
000062 65 
000118 O21 


oe COMMAND seccccces 


NAME 


MODAS 
MODAG 
MOoOCci 
MODC2 
MO0C3 
MODC4 
“O0C6 
40081 
40082 
400B4 
“ODBS 
MODE) 
“ODE2 
MODE3 
MODE4 


cop 
MOOAT 
cop 


“0043000 
MO0a4000 
400CS909 
“00C700) 
“00C8001 
40983099 
"0986009 
“09037000 
40008000 


cop 


TYPE OaTE 


sor 81/05/08 
sor 8170S5/12 
sor 81/08/14 
sor 61/08/21 
sor 81/08/28 
sor 81/08/25 
sor 81/09/01 
SOR 81/05/12 
sor 81/06/03 
sor 81/06/05 
SOR 81/06/29 
SOR 80/08/08 
SOR 80/08/08 
sor 80/08/08 
SOR 80/08/08 


01,0,,03 

OBJ 61/05/12 
O1,L,,D4 

Loo 81/05/06 
Loo 31705708 
LoD 81/06/24 


LoD 81/09/11 
Lov 00/00/00 


Lou €1/06/01 
Loo 81/07/06 
Loo 81/07/10 


Loo 81/08/24 


01,4,,05 


8060 #¢ee*eNOTHING FOUND 


LIBRARIAN FINISHED 


OATE 88/07/08 TIME 15.39 
TOTAL NUMBER OF ERRORS 03901 UPSI SETTING x*4o* 


A UTP chi ns irre tenth 


Figure 3-6. Librarian Map for Sorting Modules by Type (Part 3 of 3) 
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10.47 
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12.458 
12.38 
16044 
16.45 
16.45 
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11.10 
10.44 
10.54 
8.30 
00.08 
12.50 
14.52 
14.14 
13.31 
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3.6.3. Building Module Groups 


3-106 


This job builds two module groups by copying modules from other files. All the files 
have already been allocated. Figure 3-7 illustrates the librarian map for this job. 


Job Control Stream 





1. | // JOB GROUP 

2. | // DVC 20 // LFD PRNTR 

3. | // OVC 5@ // VOL D@Q418 // LBL ORIGINAL // LFD RG 
4. | // DVC 5@ // VOL D@Q41@ // LBL ALLLOD // LFD LD 
5. | // DVC 5@ // VOL D@41@ // LBL ALLSRC // LFD SC 
6. | // DVC 5@ // VOL DQQ41@ // LBL MIXED // LFD MX 
7. | // EXEC LIBS 

8. | /$ 

9. FIL D1=RG,D2=LD,D3=SC,D4=MX 

10. BOG  GROUPMIX,D4 

11. COP D1,S,MODA1,D4 

12. cop 3,S,MODC3,D4 

13. COP 01,0,MODA7,D4 

14. EOG  GROUPMIX,D4 

15. COP D4 

16. BOG LOADS,D1 

17. RES D2,L,MODC5@20 

18. COP.U D2,L,MODC800@,D1 

19. E0G LOADS,D1 

20. cop. D1 

21.| /* 

22.| /& 


1. Identifies the job. 

2. Assigns a printer to the job. 

3. through 6. ei 
Declare files for the job. All are on the disk volume D00410 with the logical 
unit number 50. Their names are ORIGINAL, ALLLOD, ALLSRC, and 
MIXED with logical file descriptors RG, LD, SC, and MX, respectively. 

7. Initiates execution of the librarian. 

8. Indicates the start of librarian control statements. 

9. Assigns a type and logical file number to each of the files used in the job. 


Thus, in the control statements that follow, D1 refers to the file ORIGINAL, 
D2 to ALLLOD, D3 to ALLSRC, and D4 to MIXED. 
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10. through 14. 


15. 


16. 


17. 


- 18, 


19. 
20. 
21. 


22. 


Build the group GROUPMIX in the file MIXED. The BOG statement writes 
the beginning-of-group record in the file MIXED. Line 11 copies the source 
module MODA1 from the file ORIGINAL; line 14 copies the source module 
MODCS3 from the file ALLSRC; and line 15 copies the object module MODA7 
from the file ORIGINAL. The EOG statement writes the end-of-group record 
in the file MIXED. 

Prints a table of contents for the file GROUPMIX. 


Writes the beginning-of-group record for the group LOADS in the file 
ORIGINAL. 


Sets the pointer in the file ALLLOD to the load module MODC5. 


Copies all modules from MODC5 to MODCS8 in the file ALLLOD to the group 
LOADS in the file ORIGINAL. 


Writes an end-of-group record for the group LOADS in the file ORIGINAL. 
Prints a table of contents for the file ORIGINAL. 
Indicates the end of the librarian control statements. 


Indicates the end of job. 
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SOT€ 


PpaGEe #@ oon 
UNISYS OS/3 LIBRARIAN ' WERB20401 
OATE 88/07/08 TIME 15.42 


squeeze} jO.QUOD UBLeIqrT 


6LOCK REC NAME TYPE OaTE TIME COMMENTS 

oo COMMAND cocccccce FIt O1=R6, 02=L0,03=SC,04=MX 
O 1 - VSN ITS 000410, LFo TS R6 s FILE LABEL IS ORIGINAL 
O 2 - VSN IS 000816, LFO IS LO » FILE LABEL IS ALLLOO 
0 3 - VSN IS 000810, LFO IS SC » FILE LABEL IS ALLSRE 
O 4 - VSN IS DOO0&10, LFO TIS mx » FILE LABEL IS MIXED 

oe COMMAND coccecoee BOG GROUPMIX,04& 

go0001 30s GROUPMIX 806 

oe COMMAND saccccece coe 01,5,M00A1,04 

Q0000: 045 mOOAl sor 81/04/27 09.14 

eo COMMAND secvcccce cop 03,5,M00C3,04 

ooo0gs 191 “00C3 sor 81/08/24 10.43 

ee COMMAND coecccoes cop 01,0,M00A7,04 

000009 188 MODAT OR 81/05/12 13.48 

ee COMMAND soccecces E€0G SROUPMIX,04 

300017 228 GROUPMIX £06 


oe COMMAND covcvcces cop O4 





Figure 3-7. Librarian Map for Building Module Groups (Part 1 of 3) 
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BLOCK REC 
B06 GROUPMIX 
SOURCE 
Source 
OBVECT 
€06 GROUPMIX 


oe COMMAND cocccvece 
a001867 uS8 


oo COMMAND coccccses 


ee COMMAND coccccces 


Qoo1s? 098 
00019: aos 
000198 168% 


ee COMMAND eeeeesees 
0002048 as7 


os COMMAND coscceces 


NAME 


modal 
MooCc 3 
MODAT 


BLOCKS REMA 


B26 
LOADS 


RES 


COP.u 
“oocso00 
“ooc7000 
moocsoon 
EoG 
LOADS 


cop 


TYPE OaTE TIME 


COMMENTS 
TABLE OF CONTENTS 
81/04/27 09614 
81708724 10.43 
81/05/12 13.98 
INING OIRECTORY 000000 PRIME 390901 THIRD QoOoaN 


L040S8,01 
80G 


02,L,"00C5 


D2, eM00C8,01 


Loo 91/08/24 19.54 


too 81/09/11 08.30 
Loo 00/00/00 00.08 
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EG 
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UNUSED ANANOO 


Figure 3-7. Librarian Map for Building Module Groups (Part 2 of 3) 
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BLOCK REC 


SOURCE 
Source 
SourRCcE 
SOURCE 
SOURCE 
SouRCE 
SOURCE 
source 
Loao 
Load 
SOURCE 
source 
OBJECT 
Source 
SouRCE 
Source 
source 
Source 
SOURCE 
SOURCE 
LOAD 
SOURCE 
SOURCE 
Load 
Load 
LOAD 
SOURCE 
SOURCE 
SOURCE 
SOURCE 
806 LOADS 
LOAD 
Load 
Load 
EoG LOAOS 


LIBRARIAN FINISHED 


40001 
40002 
"0003 
"OODS 
moons 
MO006 
MOOAL 
MODA2 
“ODA 3000 
m00a48000 
MODAS 
MODA6 
MODAT 
mooci 
Mooc2 
MOOC 3 
Monoc4 
mOOC6 
M0081 
MO0B2 
™0D8 3000 
MO0B4 
MO085 
40036900 
4008 7000 
4008 8090 
MODEL 
MODE 2 
MODE 3 
MODES 


400C 5000 
MOOC 7000 
MOnC 3090 


TYPE 


80/08/08 
80/08/08 
80/08/08 
80/08/08 
80/08/08 
60/06/08 
61/04/27 
81/08/27 
61/05/06 
81705708 
$1/05/08 
81/05/12 
81/05/12 
81/08/14 
81/06/21 
61/08/24 
61708724 
81/09/01 
81/08/12 
81/06/01 
81/06/01 
81/06/05 
81/06/29 
81/07/06 
81/97/10 
81/08/14 
80/08/08 
80/06/08 
80/08/08 
80/08/08 


61/09724 
81/09/11 
oo/aaso0 


BLOCKS REMAINING 


DATE 88/07/08 TIME 15.42 
TOTAL NUMBER OF ERRORS 00000 UPSI SETTING x*O0* 





PAGE # 0003 
oatTe TINE COMMENTS 


TABLE OF CONTENTS 


16.34 
16.35 
16.37 
16.39 
16.41 
16.43 
09.14 
09.22 
11.10 
10.44 
11.06 
13.45 
13.98 
13.35 
10.S1 
10.43 
10.47 
10.28 
13.59 
12.33 
12.50 
12.45 
12.38 
14.52 
14.14 
13.3% 
16.44 
16.45 
16.45 
16.47 


10.54 


08.30 
ag3.08 


DIRECTORY OOO000 PRIME OO0GO THIRD 000000 UNUSED 909000 





Figure 3-7. Librarian Map for Building Module Groups (Part 3 of 3) 
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Librarian Control Statements 


3.6.4. Copying Cards to a Disk File 


This job copies cards to a module in a disk file. In this case, the cards contain the 
sample job control stream explained in 3.6.2, except that the job is called SRTFLS. 
Figure 3-8 illustrates the librarian map for this job. 


Job Control Stream 
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34. 





// JOB SAVEDECK 

// OVC 20 // LFD PRNTR 
// OVC 5@ = // VOL DQ0410 
// LBL YOURSRC // LFD YR 
// EXEC LIBS 


FIL D1=YR 
ELE.D D1,S,SRTFLS,SORTS MODULES BY TYPE 


// JOB SRTFLS 
-1// OVC 20 // LFD PRNTR 
«1// DVC 5@  // VOL 080410 
-1// LBL ORIGINAL // LFD RG 
-|// DVC 58 // VOL DOQ418 
-|// LBL ALLSRC // LFD SC 
-|// DVC 58 // VOL DQ0410 
-|// LBL ALLOBJ // LFD OB 
-|// DVC 58 // VOL D@G418 
-j// LBL ALLLOD // LFD LD 
-|// DVC 58 // VOL 000410 
-|// LBL ALLMAC // LFD MC 
// EXEC LIBS 


/$ 
FIL D1=RG,D2=SC,D3=0B,D4=LD, D5=MC 
cop 1 
COP 1,S,,D2 
cop p1,0,,D3 
COP D1,L,,D4 
COP 01,M,,D5 
/* 
/& 
EOD 
/* 
/& 
// FIN 
Identifies the job. 
Assigns a printer to the job. 


Identifies the logical unit number 50 for the disk volume D00410, which 
contains the file where the module is to be stored. 
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4. Declares the file YOURSRC and the logical file descriptor YR for the file 
where the module is to be stored. 

5. Initiates execution of the librarian. 

6. Indicates the start of the librarian control statements. 

7. Assigns a type code and logical file number to the file YOURSC. Thus, D1 in 
line 8 refers to the file YOURSRC. 

8. Indicates the beginning of the cards. It also supplies a name SRTFLS for the 
module once it is added to the disk file YOURSRC. The comment SORTS 
MODULES BY TYPE will be included in the module header record. The D 
option causes the records in the module to be listed on the librarian map. 

9. through 30. 

Are the cards in the librarian control stream being saved. 

31. Indicates the end of the cards. 

32. Indicates the end of the library control statements for the job. 

33. Indicates the end of job. 

34. Ends card reader operation. 
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¥ ABY THESdl1 


elle 


UNISYS OS/3 LIBRARIAN 
DATE 88/07/08 


SLOCK 


REC 


ee COMMAND 


ee COMMAND 


Quaod1 
300001 
900001 
900001 
ao0001 
gg0001 
ooo0dt 
gouo02 
Jou0de2 
gqa0d2 
200002 
joggg2 
j00002 
WAuUV2 
agu0002 
oaudu3 
300005 
ojgiu? 
300993 
udu0u$ 
399003 
200003 
youoo3 


0as 
N63 
1183 
113 
144 
177 
208 


uus 


a36 
uo7 
4938 
129 
160 
191 
2lu 
325 
246 
064 
U3U 
luau 
120 
14J 
149 


TIME 15.53 


NAME 


FIt 


0 


ELE.D 


SRTFLS 


JOB 
Jvc 
Ovc 
L3L 
Ove 
LBL 
Ove 
L3L 
Ove 
LPL 
Ovc 
LSL 





TYPE OATE TIME COMMENTS 


Di=yvR 


1 - VSN IS 0N0410, LFO IS’ YR 


2 FILE LABEL IS YouRSeC 


O1,S,SRTFLS,SORTS MODULES 3Y TYPE 


sor 


SRATFLS 
20 «4 
30 4A 


82/07/08 15.83 SORTS MOOULES BY TYPE 


LFD PRNTR 
vol 000419 


ORISINAL // LFOD RG 


so 4 
ALLSRC 
50 
ALLOBJ 
50 4 
ALLLOO 
50. 4/ 
ALLMAC 


EXEC LIRS 


FIL 
cop 
cap 
cop 
cop 
cop 


Figure 3-8. Librarian Map for Copying Cards to a Disk File 


VOL 000410 
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VOL 009410 
47 LF9 9S 
Vol 009410 
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DI 
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D1 909993 
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Oly» 205 
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VERS20801 
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3.6.5. Creating and Running a Librarian Job Interactively 


The following sample session illustrates how to create a librarian job control stream 
interactively at a workstation, save it on disk, and then run the librarian job. 













000000 SSSS 


00000000 SSSSSS // 33333 

eo 00 ss Ss /t1 3333 
00 oo ss 4 33 
00 00 ss ‘tf 33 

00 00 ss 4/1 333 
oo 00 ss Jit . 33 
00 00 ss ss ‘tT 3333 
00000000 SSSSSS // 3333333 





000000 Ssss / 3333 








INTERACTIVE OPERATING SYSTEM 
DEPRESS TRANSMIT FOR LOGON 


OS/3 INTERACTIVE SERVICES 
LOGON IDENTIFICATION: USER-ID 
ACCOUNT NUMBER 
PASSWORD 





OPTIONS: EXECUTION PROFILE 
BULLETIN 
LOG 
NEW PASSWORD 


LOGON USER1, BULLETIN=NO 


000000 SSSS 

00000000 SSSSSS 
00 00 ss Ss 33.33 
00 00 ss 33 
00 00 ss 33 
00 00 ss 333 
00 08 Ss 33 
OT) oe ss ss 33.33 
00000000 SSSSSS 3333333 
900000 SSss 3333 


INTERACTIVE OPERATING SYSTEM 
DEPRESS TRANSMIT FOR LOGON 
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FUNCTION Zz 
{| [ss \ 


EDT 


OS/3 EDITOR READY (VERSION XXX) 
1.0088// JOB SAVSRC 

2.0008// DVC 20 // LFD PRNTR 
3.0008// DVC 5@ // VOL PUBDSK 
4.0000// LBL ORIGINAL // LFD RG 
5.8000// OVC 58 // VOL PUBDSK 
6.0000// LBL ALLSRC // LFD SC 
7.0800// DVC 5@ // VOL PUBDSK 
8.0000// EXEC LIBS 


9.0000/$ 

10.0000 FIL = D1=RG,02=sc 
11.0088 cop D1 

12.0000 cop 01,S,,D2 
13.0000 cop - b2 
14.0000/* 

15 .0000/& 


16. 0@00QWRITE MO=SAVSRC, TYPE=S, FIL=MYJOB, VSN=DSKQ01,S1ZE=18, SAT=YES 
17. @@@GQDELETE 
18. @@@@QHALT 


FUNCTION f:\ i 





[ev SAVSRC: (MY JOBS , DSK801) 


= = 


LOGOFF ; 
IS73 LOGOFF ACCEPTED AT 14:34:60 ON 88/09/12 
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11. 


12. 


13. 
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Start with the idle workstation display. 
Log on at the workstation in either of two ways: 


a. Press the XMIT key to display the logon screen, fill in the entries, and 
press the XMIT key again. 


b. Key in the LOGON command and press the XMIT key. 


Place workstation in system mode. Hold down the FUNCTION key and, 
while holding it down, press the SYS MODE key. 


Activate the general editor (EDT). Key in EDT on the top line of the screen 
and press the XMIT key. 


The first workspace line number is displayed. Key in the job control stream. 


Key in an EDT WRITE command to save the job control stream as a source 
module in a SAT file. Here, the module name is SAVSRC; its type is S for 
source. SAT=YES saves it in a SAT file. The file is named MYJOBS and is 
located on the disk volume named DSKO001. The SIZE parameter allocates 
10 cylinders for the new file. If the file MYJOBS already exists on DSK001, 
the SIZE parameter must be omitted. 


After the module is saved, key in an @DELETE command to clear the © 
workspace. 


Key in an @HALT command to terminate EDT. The workstation returns to 
workstation mode. 


Place the workstation in system mode. Press the FUNCTION key and, while 
holding it down, press the SYS MODE key. 


Key in RV command to run the job. and press the XMIT key. The 
workstation returns to workstation mode. 


When a job completion message is displayed, place the workstation in 
system mode. Press the FUNCTION key and, while holding it down, press 
the SYS MODE key. 


Log off of the workstation. Key in the LOGOFF command and press the 
XMIT key. 


A successful logoff message is displayed. 


. 
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Section 4 
Functional Characteristics 


4.1. Introduction 


The OS/3 linkage editor is a multiphase load module that resides in the system load 
library file ($Y$LOD). It relies on allocation of both system disk and main storage free 
space for intermediate processing efficiency as well as one or more system or user 
object libraries for obtaining the desired object code. The load modules the linkage 
editor produces subsequently can be stored in either the system load library file or a 
user load library file. All reentrant load modules must be stored in the system load 
library file ($Y$LOD). The system access technique (SAT) is used in the management 
of all files accessed by the linkage editor. Figure 4-1 illustrates the functional 
relationships between the linkage editor, SAT, and the various interfacing files. 


The linkage editor relies on an input control stream for acquisition of control 
statement directives and parameter information. In the absence of such a control 
stream, the linkage editor defaults to the appropriate system job run library 
($Y$RUN) file to obtain the modules to be used in constructing the load modules. The 
6 program name of the linkage editor is LNKEDT. 






SYSTEM 

LOAD 

LIBRARY 
iT 






FILE 
(SY$LOD) 














SYSTEM SYSTEM 
OBJECT 


AGE 
LIBRARY LINKAG 


EDITOR 





|, OBJECT PHASED 


<---> LINKAGE 
EDITOR 





JOB RUN 
LIBRARY 
FILE 
{SY$RUN) 






INTERMEDIATE 
STORAGE 





FINAL STORAGE 


Figure 4-1. Functional Relationship between the Linkage Editor, SAT, and Related Files 
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4.1.1. The SAT Interface 


42 


The linkage editor uses the system access technique for the following purposes: 


¢ Reading system and user libraries to obtain the necessary object modules to be 
included in the load module. 


¢ Managing an intermediate scratch file during the link-edit process. 
¢ Creating the final output load module or modules. | 


Because the linkage editor is producing standard load modules (as needed by the 
system) and is accessing standard object modules (as produced by the various 
language processors), all of which are contained in disk program library files, the SAT 
file definitions (DTFs) describe three partitions for each file. The first partition is the 
directory partition used as an index into the second and third partitions, the data 
partitions of the library file. Because the output of the linkage editor is essentially a 
library file (load module type), it too contains both a directory partition and two data 
partitions (the directory is composed primarily of phase header pointers and the third 
partition is empty). 


The load modules produced by the linkage editor contain phase header records (one 
for each phase segment); text/RLD records comprising the actual instructions, 
constants, and relocation information making up each individual phase; transfer 
records (one at the conclusion of each phase); ISD records and, optionally, shared code 
records. Each phase header contains an appropriate entry in the load library directory 
(first partition), which identifies the load module and the particular phase and points 
to the relative position within the data body of the library file (second partition). For 
each phase header entered in the body of the load module (second partition), the 
necessary directory entries also are entered in the directory index (first partition) with 
the relative pointer obtained from the necessary DTF description for the second 
partition. Both the directory and prime data areas of the file contain blocked logical 
records. 





The object modules that the linkage editor uses in its construction of the load module 
are also retrieved through the SAT. These files are accessed through a file directory 


- sean (first partition) in an attempt to locate the necessary module header, control 


section definition, or entry symbol definition. (Object library file directories are 
supplemented with named CSECTs, COMs, and ENTRYs to facilitate this search.) 
When the desired directory item is found, the relative directory pointer is extracted 
from the record and copied into the second partition definition of the DTF to obtain 
the needed modules or control sections from the body of the module. 


The intermediate scratch file used by the linkage editor in the course of the link-edit 
job and seen only by the linkage editor for its processing, also is accessed via SAT. 
This file is scratched when the link-edit job is finished. 
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4.1.2. Temporary Storage Usage 


The linkage editor uses open storage space at the end of its longest path for the 
management of temporary reference tables and buffers. This area is reserved by the 
linkage editor when it is first loaded into main storage. In a minimum storage system, 
the reserved area is always equal to the size of the maximum storage partition 
allowed any user program. In larger system configurations, this reserved area is 
dynamically expanded at linkage editor execution time. 


If any job step in a job containing a linkage editor job step requires an amount of 
storage in excess of the minimum linkage editor storage requirements, the linkage 
editor uses the excess for reference table and buffer expansion. Because job control 
assigns storage requirements for a given job based on the largest requirement for any 
job step, when not specified explicitly on the // JOB control statement, the linkage 
editor adjusts its pointers (as originally established) to accommodate the availability 
of the extra tabling space (if any extra exists). The linkage editor determines the 
amount of storage space allocated for the job (of which it is a step) by examining the 
job prologue. The speed of the link-edit is proportional to the amount of main storage 
space available to the linkage editor. 


If a given link-edit job involves a number of definitions with table entries exceeding 
the current internal storage space available for that job step, the linkage editor 
expands the reference table by using data blocks on the temporary output medium via 
the DTF partition assigned to the intermediate file. Thus, table overflow does not 
cause the link-edit job to be aborted. 


4.2. Linkage Editor Inputs and Outputs 


The linkage editor uses as input both job control stream data in the form of linkage 
editor control statements and object module elements and produces, as output, one or 
more load modules and a link-edit map for each load module (see Figure 4-2). Under 
normal operating conditions (no normal linkage editor options suppressed or 
superseded), the linkage editor uses the control statements contained in the job 
control stream to construct one or more load modules per job. These statements, which 
comprise the primary control stream input to the linkage editor, specify the object 
modules to be included in the load modules, the structure of the load modules to be 
produced, and the linkage editor options to be in effect during construction of the load 
modules. 


The object modules referenced in the primary control stream also may have linkage 
editor control statements embedded in them. When they do, these control statements 
are effectively inserted in the primary control stream at the point the object module 
containing them was referenced, and thus become part of the primary control stream 
input. 
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The control statements contained in the primary control stream input also may 
identify source modules containing linkage editor control statements to be processed 
during the job step. When such statements are processed, the control statements they 
reference also are effectively inserted in the primary control stream input just like 
embedded control statements. These statements, however, have special processing 
significance attached to them and are thus referred to as source module control 
stream statements in this guide to differentiate them from the other two types of 
primary control stream statements (job control data and embedded control 
statements). 


The load modules produced by the linkage editor normally are output to the system 
job run library file ($Y$RUN). The user, however, may direct his output to be stored in 
any library file he wishes, or he may elect to suppress this output entirely through the 
linkage editor control statement options available to him. The same is true for the 
link-edit map, which normally is output by the linkage editor for each load module it 
produces, whether or not the load module output is suppressed. This output also can 
be suppressed by the user through a linkage editor control statement option. Each 
link-edit map describes the control statements used to construct its associated load 
module, the symbols, or labels, detected in the object modules included in the load 
module, the structure of the load module produced, and any processing errors that 
might have been detected during construction of the load module. Detailed 
descriptions and illustrations of the map components are presented in Section 7. 


INPUTS OUTPUTS 


LINKAGE EDITOR 
CONTROL 


STATEMENTS 
LOAD 


MODULES 












PRIMARY CONTROL 
STREAM INPUT 











JOB CONTROL 
STREAM DATA 


PROGRAM LIBRARY 
FILE 


SOURCE MODULE 
REFERENCED] CONTROL STATEMENTS 
SOURCE 

MODULES 







LINKAGE 
EDITOR 





PROGRAM LIBRARY 
FILE 









LINK-EDIT 
MAP 


SYSTEM PRINTER 





EMBEDDED CONTROL STATEMENTS 





INCLUDED 
OBJECT 
MODULES 






OBJECT MOOULE ELEMENTS 


PROGRAM LIBRARY .- 
FILE 


Figure 4-2. Linkage Editor Inputs and Outputs 
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@ 4.3. Control Statement Functions 


Control statements are available to the user to direct the linkage editor in 
construction of a load module. These statements allow the user to generate a load 
module that is structured in accordance with his program requirements, as these 
requirements exist in the object elements that are to make up the load module. 
Linkage editor control statements normally appear as data in a job control stream 
following an execute linkage editor job control statement (// EXEC LNKEDT). As 
previously indicated, however, linkage editor control statements also can be embedded 
in object modules or contained in source modules referenced by linkage editor control 
statements. Therefore, if no control statements are present in the job control stream 
following a // EXEC LNKEDT control statement, the linkage editor constructs a load 
module by using all the object. modules currently contained in the job’s job run library 
file ($Y$RUN). If none of the object modules contained in this file contain embedded 
linkage editor control statements, the linkage editor constructs only one nonreentrant 
single-phase load module, named LNKLOD, consisting of all the object modules 
contained in the $Y$RUN library file; otherwise, if so directed by embedded control 
statements, the linkage editor may produce multiple load modules, reentrant or 
otherwise, with or without multiphase and multiregion structures. 


The name and basic function of each of the linkage editor control statements are 
described in the following paragraphs. A more detailed description of these control 
statements is presented in Section 6. 
© ¢ // PARAM and LINKOP Statements. These statements specify the linkage editor 
processing options that are to be in effect during construction of a load module. 
These options include: 
- Determining file name assumption to be used by the INCLUDE mechanisms 
of the linkage editor when such file names are not explicitly designated by 
the user 


-  Disallowing the automatic inclusion of object modules in the load module by 
the linkage editor 


-  Disallowing the automatic overlay mechanism of the linkage editor from 
being included in the load module 


-  Disallowing the promotion of common storage sections by the linkage editor 


- Selecting the output file in which the load module created by the linkage 
editor is to be stored 


- Terminating a link-edit job if a processing error is detected 


- Selecting the components of the link-edit map to be output for a given link- 
edit job 


- Inserting comments in the phase header records produced by the linkage 


& editor 


UP-8841 Rev. 4 45 


Functional Characteristics 








- Building reentrant load modules 
- Ignoring the reentrancy of object modules 
-  Suppressing the production of ISD records 


¢ LOADM - Begin Load Module. This statement requests the linkage editor to 
begin construction of an executable load module. This statement initiates the 
creation of the start of the root phase segment and specifies a name for the load 
module. It normally is the first control statement in each link-edit job. 


° INCLUDE - Include Object Code. This control statement instructs the linkage 
editor to include an entire object module or specific object module sections in the 
load module being constructed. This statement specifies the name of the object 
module and module sections, if applicable, that are required to be in the load 
module segment currently under construction. It may also identify the file in 
which the specified module is located. 


© OVERLAY - Begin Overlay Phase. This statement directs the linkage editor to 
begin construction of a new load module phase separate from the initial phase 
and any other previously defined phase. Any and all INCLUDE requests for 
object code following an OVERLAY statement are included in the phase initiated 
by the OVERLAY statement up until the detection of another OVERLAY or 
REGION control statement or termination of the immediate link-edit job. The 
phase name assigned to the overlay phase is a combination of the name assigned @ 
to the load module plus a two-digit number from 00 to 99, which indicates the 
order in which the various phases of a load module were declared to the linkage 
editor. A unique six-character alias-phasename also may be assigned to each 
overlay phase. 





¢ REGION - Begin New Region. This statement causes a new phase to be created in 
a new region of the load module. This statement has all the attributes of the 
OVERLAY statement, and, in addition, initiates the construction of a new load 
module region. 


¢ ENTER - Define Phase Execution Entrance. This statement specifies the start-of- 
execution point for the phase currently under construction in a load module. This 
is the point to which control is optionally transferred once the phase has been 
loaded in main storage. The transfer point is optionally assigned by the linkage 
editor if no such statement is supplied for a phase. This statement is normally the 
last specified for each phase defined in a load module. 


¢ EQU - Define Label. This statement is used to define an otherwise undefined 
label in a load module. The normal method of defining and satisfying cross- 
references by the linkage editor is via the proper INCLUDE directives and 
external symbol dictionary (ESD) records in object code included in the load 
module. This statement, however, allows the user to equate two symbols, a 
symbol and a value, or a value only, that could not otherwise be resolved in the 
link-edit run. If one symbol is being equated to another, the equating symbol 
must have been previously defined. @ 
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MOD - Modify Location Counter. This statement is used to modify the current 
program counter that the linkage editor maintains during construction of a load 
module. This statement permits the user to accomplish boundary adjustments at 
link-edit time outside the realm of the makeup of modules and code being 
included. 


RES - Reserve Storage. This statement directs the linkage editor to reserve 
additional storage at the end of the longest path in the load module being 
constructed. The additional storage requested is included in the overall length of 
the load module as recorded in the load module header record, and may be 
referenced by the object code included in the load module. 


4.4. Object Module Format 


The format of the object modules produced by all the language processors and used as 
input by the linkage editor is illustrated in Figure 4-3. As shown, an object module 
consists of: 


UP-8841 Rev. 4 


Object module header record that uniquely identifies the object module. 


One or more control section records, each of which defines the symbolic name, 
external symbol identification (ESID), and length of each control section (CSECT 
and COM) comprising the object module. 


Possibly one or more external symbol dictionary (ESD) records, each of which is 
used by the linkage editor in satisfying cross-references (ENTRY, EXTRN, and 
V-CON references) between object modules during the link-edit operation. 


Possibly one or more internal symbol dictionary (ISD) records used to describe 
the internal symbols of the user program. 


One or more text and relocation list dictionary (RLD) records containing the data 
and instructions making up the object code, together with relocation masks used 
by the linkage editor to modify specific areas of the object code at link-edit time. 


Transfer (TRF) record that may optionally indicate a start-of-execution address 
for the object module. The transfer record is normally the last record in any set of 
relocatable object code produced by a language processor. 


One or more linkage editor control statements that may be embedded in an object 


module. Embedded control statements may appear only immediately following 
the object module header record or transfer record (see Figure 4-3). 
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OBJECT MODULE HEADER RECORD 


LINKAGE EDITOR CONTROL STATEMENTS 
(OPTIONAL) 
CONTROL SECTION RECORDS 


EXTERNAL SYMBOL DICTIONARY (ESD) 
RECORDS (OPTIONAL) 
TSD RECORDS (OPTIONAL) 


TEXT/RELOCATION LIST DICTIONARY 
RECORDS 
TRANSFER RECORD 


LINKAGE EDITOR CONTROL STATEMENTS 
(OPTIONAL) 


Note: 












Control section and ESD type records must have unique 
names within a given object module. For example, an entry 
point and a CSECT must not have the same name and exist 
in the same object module. 





Figure 4-3. OS/3 Object Module Format 


4.5. Load Module Format 


The format of the load modules produced by the linkage editor, as they are stored in a 
library file, is illustrated in Figure 4-4. As shown, all load modules consist of at least 
one phase called the root phase. Multiphase and multiregion load modules consist of a 
root phase plus one or more additional phases. (A root phase is required in every load 
module because it contains the information necessary to allocate the load module 
space in main storage prior to its execution by the system.) The number of phases and 
regions comprising a load module is specified by the user in the linkage editor control 
stream that produces the load module. A load module may consist of up to 100 phases 
and up to 10 regions. 
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PHASE HEADER RECORD 
SHARED RECORDS ONLY PRESENT IF REQUIRED 
iSD RECORDS 
AUTOMATICALLY INCLUDED ONLY PRESENT IF REQUIRED 
OBJECT CODE AND AUTOMATIC INCLUSION 
FEATURE IS NOT INHIBITED 
aoor AUTOMATIC OVERLAY CONTROL ROUTINE ONLY PRESENT WHEN V-CON 
SuAGE (KLSOCP OR KLSOCPR) PROCESSING IS SPECIFIED 
aN | ets ee AND VALID V-CON 
ENTRY POINT TABLE (NTAB) REFERENCES EXIST IN 
Eh ae as a aaa te FCC a MULTIPHASE OR MULTI- 
PHASE TABLE (PTAB) REGION LOAD MODULES 
REGION TABLE (RTAB) 
SPECIFICALLY INCLUDED 
OBJECT CODE 
TRANSFER RECORD 








PHASE HEADER RECORD 


PHASE 1 
SEGMENT 


SPECIFICALLY INCLUDED 
OBJECT CODE 


TRANSFER RECORD 









PHASE HEADER RECORD 


PHASE N 
SEGMENT 
(UP TO 99) 


SPECIFICALLY INCLUDED 
OBJECT CODE 


TRANSFER RECORD 





Figure 4-4. OS/3 Load Module Format 
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Each phase of a load module consists of at least the following: 


A phase header record that identifies: 

- Name of the phase 

- Size of the phase in bytes and its origin 

- Amount of main storage required to load the longest path of the load module 
At least one (and probably more) text/relocation (RLD) record that includes both 
data and instructions comprising the load module phase and possible relocation 


masks to be used to relocate the text at execution time. 


A transfer record identifying the end of the phase, and containing a transfer 
address at which point phase execution is to optionally begin. 


In addition to these records, the root phase of a load module may contain: 


Any number of shared records. A reentrant load module will have one or more 
SENTRY records indicating the availability of ENTRY points in that module. A 
nonreentrant load module will not have any shared records unless it references 
reentrant code. In this case, it will have a resource record and a SEXTRN record 
for each reference that was resolved to a reentrant object module. 


- Resource records contain the name of the reentrant module referenced. 
- | SEXTRN records identify the EXTRNs that were resolved to the resource. 
Any number of ISD records. The ISD records can be one of the following: 


- | CSECT/COM ISD records identifying control and common sections included 
by the linkage editor. 


- ISD records produced as a result of being generated by any of the language 
processors within object modules. 


Any automatically included object module sections that are needed to satisfy any 
cross-references not defined in any specifically included object module section. 


An automatic overlay control routine if the load module produced requires the 
automatic loading of its phases. Two versions of this routine exist: one handles 
single-region structures (SL$OCP) and the other handles multiregion structures 
(KL$OCPR). 


An entry point table (NTAB), used in conjunction with the automatic overlay 
control routine, to provide for automatic loading of phases. This table contains the 
addresses of referenced ENTRY points and an index into the phase table (PTAB) 
which identifies the phases containing the ENTRY points. 
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¢ Aphase table (PTAB), used in conjunction with the automatic overlay control 
routine, to provide for automatic loading of phases. This table contains the 
overlay structure information required to load the various phases of the load 
module. 


¢  Aregion table (RTAB), used in conjunction with the automatic overlay control 
routine, to contro] automatic loading of the various regions that may be in the 
load module. This table describes the region structure of the load module and is 
present only if the KL$OCPR automatic overlay control routine, with multiregion 
control, is present. 


When a load module is loaded in main storage for program execution, only its 
instructions and data are loaded; phase header, shared records, ISD records, and 
transfer records are not included. These records are used only to: 


¢ Relate the amount of main storage required to store the load module and the 
particular phase being loaded, including any common storage areas and reserved 
storage areas required by the load module program 


¢ Identify the phase load address 
¢ Identify the program starting address 


¢ Identify the resources (reentrant load modules) that are needed and SEXTRNs to 
& be satisfied at execution time 


e Identify the entry points that are available in reentrant load modules at 
execution time : 


¢ Give JOBDUMP the necessary information to print a dump of segmented 
CSECTs of the program and internal symbols of the user program 


Figure 4-5 illustrates the format of a typical load module as it might appear in main 
storage. As shown, it might have a common storage area and a reserve storage area. 
These areas are storage areas that the linkage editor reserves for the load module 
program in accordance with the common storage area definitions contained in the 
object module code included in the load module and the reserve storage (RES) control 
statements contained in the linkage editor control stream that created the load 
module. The size of the common storage area reserved for a load module is the sum of 
all the common storage areas requested and described by both the specifically 
included and automatically included object modules in the load module. Common 
storage areas may be labeled or unlabeled in the object module code. The size of the 
reserve storage area reserved for a load module is the sum of all the reserve storage 
areas specified by the user in all RES control statements. 
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COMMON STORAGE AREA* 
(AS REQUIRED) 


AUTOMATICALLY INCLUDED 
OBJECT MODULES 
ROOT (AS REQUIRED) 
PHASE 


OVERLAY CONTROL REQUIRED ONLY WHEN 
ROUTINE AND TABLES AUTOMATIC LOADING OF 
(1F REQUIRED) PHASES IS REQUIRED 


SPECIFICALLY INCLUDED 
OBJECT MODULE ELEMENTS 
{AS SPECIFIED BY 
INCLUDE STATEMENTS) 





SPECIFICALLY INCLUDED 
OBJECT CODE 
FOR OTHER 
PHASES 


RESERVE STORAGE 


AREA 
(AS SPECIFIED) 





*Common storage areas also may be promoted to specific phases 
other than the root phase by the linkage editor (see 4.7.3). 


Figure 4-5. Typical Load Module Format when Loaded in Main Storage 
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4.6. Load Module Structure 


The structure of a load module is that form a load module takes when it is loaded in 
main storage by the program loader routine of the supervisor. This structure is 
defined by the phase and region data contained in the load module as placed there by 
the linkage editor in accordance with the control stream directives by the user. Three 
basic load module structures are capable of being constructed by the linkage editor: 


e¢ Single-phase load modules 
¢ Multiphase load modules 


¢ Multiregion load modules 


4.6.1. Single-Phase Load Modules 


The storage structure of a single-phase load module can be represented by a single 
horizontal line whose length is relative to the amount of serial storage locations 
required to store the load module in main storage. All load modules generated by the 
linkage editor start out as single-phase load modules and are created only as 
multiphase or multiregion load modules if so directed through OVERLAY and 
REGION control statements in the input control stream. Thus, single-phase load 
modules are modules that consist solely of a root phase; multiphase and multiregion 
load modules consist of a root phase plus one or more additional phases. Reentrant 
load modules must be single-phase load modules. 


4.6.2. Multiphase Load Modules 


Multiphase load modules are constructed by a programmer to minimize the main 
storage requirements of a program. Multiphase load modules contain multiple phases, 
which can overlay each other in main storage. The structure of a typical multiphase 
load module is illustrated in Figure 4-6. As shown, multiphase load modules are 
represented by multiple horizontal lines, each of which represents a particular 
program phase and its relative length. The main storage location at which a phase is 
loaded is called a node point. Node points are shown as vertical lines whose lengths 
have no significance. All the phases in a multiphase load module excluding the root 
phase are loaded in main storage at a node point. Node points and phases are defined 
by the user through the linkage editor OVERLAY and REGION control statements. 


The INCLUDE statements following an OVERLAY or REGION control statement 
identify the object module elements that are to comprise the phase. Ignoring the root 
phase, the number of phases in a multiphase load module coincides with the number 
of OVERLAY and REGION control statements present in the control stream that 
caused its generation. The root phase of all load modules is initiated with the 
initiation of the load module, normally in response to a LOADM control statement. 
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NOTES: 


1. Heavy lines indicate an example of a path. 


2. The end address of the !oad module is the last addressable location of the tongest path in the load module. This address 
is always defined and may be declared as an external reference (EXTRN) in any object module included in the program. 
The entry name assigned this end address is KESALP. 


Figure 4-6. Typical Multiphase Load Module Structure 
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The OVERLAY control statements required to produce the multiphase load module 
shown in Figure 4-6 are illustrated in Figure 4-7. 
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Note: The ellipses represent INCLUDE statements for object modules to be included in a partic Jar phase. 
These statements must follow the proper LOADM or OVERLAY statement. 


Figure 4-7. Typical Multiphase Load Module Control Stream 


Phase Definitions 


Phases are defined by the user beginning with an OVERLAY or REGION control 
statement (root phases excepted), and are usually followed by one or more INCLUDE 
control statements that identify the object module elements that are to comprise the 
phase. A load module phase may be thought of as a program segment that can 
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perform one or more specific processing tasks. The order in which phases are defined 
by the user does not dictate the order in which the phases in a load module must be 
executed; the logic of the program determines the sequence of execution of the phases 
contained in a load module and, likewise, the number of times any specific phase will 
be loaded and executed. In some programs, not all phases are executed each time the 
program is executed, again, depending on the logic of the program. 


Thus, the order in which phases are defined, which is also the order in which they are 
numbered by the linkage editor, does not necessarily have any bearing on the order in 
which the phases of a load module are executed. 


The node point assigned to each phase usually does, however, determine where the 
phase will be loaded in main storage. Thus, a program’s logic must be considered 
before one phase of a load module is assigned the same origin as another phase in the 
load module, because these phases never can be in main storage simultaneously. 


Phase Names 


Phase names are used to identify the various phases of a load module when they are 
to be loaded in main storage for program execution. Programmers who wish to do their 
own program loading, rather than have the automatic overlay-region control 
mechanism of the linkage editor embedded in their load module, must reference a 
phase name in a FETCH or LOAD macro instruction whenever a phase is to be loaded 
for execution. 


The linkage editor automatically assigns a name to each phase of a multiphase load 
module based on the name assigned to the load module either by the programmer or 
the linkage editor. Phase names consist of eight alphanumeric characters. The first six 
characters are the same as the load module name and the last two characters are the 
decimal number of the phase (00 through 99). Phase numbers are assigned to each 
phase consecutively, in the order in which the phases are defined by OVERLAY and 
REGION control statements. 


An alias phase name also may be assigned to each phase by the programmer through 
the OVERLAY or REGION control statement that causes its generation. The 
assignment of alias phase names allows the programmer to reference the phases of a 
load module in his subroutines or phrases, without knowing the order in which the 
phases will be defined in the linkage editor control stream. The linkage editor overlay 
control mechanism always refers to the linkage-editor-generated phase names. 


Node Points and Paths 


The starting address of each phase in a load module is called a node point. Node 
points are defined by the user as a symbol in the operand field of the OVERLAY or 
REGION control statements that are used to define each phase. The node point of the 
root phase is the name assigned to the load module. The starting address of one phase 
is normally the terminating address of a previous phase (it also could be a relative 
definition in the current path). The same node point may be the assigned origin of 
more than one phase in a load module; however, when an OVERLAY statement that 
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refers to a node point previously defined is detected by the linkage editor, all 


- intervening node points are eliminated. For example, in Figures 4-6 and 4-7, once 


phase 6 is defined, no additional phases may be defined starting at NODE3. Also, once 
phase 7 is defined, no additional phases may be defined starting at NODE2. If phase 7 
were followed by an OVERLAY NODE2 statement, the linkage editor would construct 
anew NODE2 node point at the end of phase 7 for the new phase being defined. 


References to a given label in the load module may be traced along a path from one 
phase back to the root phase. Reference x is said to be on the path of phase y if they 
are in the same phase, or if they are on the same path and reference x is closer to the 
root phase than phase y. The root phase is usually on the path of every other phase in 
a load module, except when it is overlaid by a subsequent phase. In Figure 4-6, phases 
0,1, 3, and 5 are on the path of phase 5, as indicated by the heavy line; however, phase 
5 is not on the path of phases 0, 1, or 3. Phase 1 is not on the path of phase 7, and 
phase 7 is not on the path of phase 1. The maximum number of phases allowed on any 
path is 14. 


The path concept ofa load module must be understood before the user can appreciate 
how the linkage editor satisfies references between various load module phases. 


Communications between Phases 


Communications between phases is accomplished by an external reference in one 
phase whose name matches a definition (CSECT or ENTRY point) in another phase. 
The language processors may produce two types of external references. The first is a 
standard (type A) address constant which, at execution time, will contain the linkage- 
editor-assigned address of the associated definition. The second is a type V address 
constant, which, in effect, requests that an automatic load mechanism ensure that the 
definition being referenced is resident at the time the reference is made. A linkage 
editor option allows the user to convert, at link-edit time, all type V EXTRNs to 
standard address constants. 


The phase structure of a particular load module determines another characteristic of a 
given reference. If the definition to which a particular EXTRN refers is on the path of 
the reference, the reference is said to be inclusive. All inclusive references are treated 
as standard address constants by the linkage editor regardless of the EXTRN type 
generated by the language processor. Conversely, if the definition that satisifies a 
particular reference is not on the path of the reference, the reference is said to be 
exclusive. It is these exclusive references that can be controlled by the user through 
the linkage editor (V/NOV) option. Figure 4-8 illustrates both inclusive and exclusive 
references. 


If a type V exclusive reference is made, the linkage editor puts the address of the 
definition in a table it generates (NTAB) in the root phase of the load module. The 
reference address is then made to point to an automatic overlay control routine. This 
control routine ensures that the required path is loaded before transferring control to 
the required definition. All other references require that the user ensure that the 
required definition is loaded, when referenced, through the supervisor FETCH and 
LOAD macroinstructions contained in the text of his program. 
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Figure 4-8. Examples of Inclusive and Exclusive References 
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® 4.6.3. Multiregion Load Modules 


Multiregion load modules are basically the same as multiphase load modules, except 
that a multiregion load module is constructed so that the origin of the first phase of 
each region is at the end of the longest path defined in the previous region, rather 
than at the end of the phase previously defined. This feature prevents the phases in 
one region from overlaying any portion of a phase in any other region. The structure of 
a typical multiregion load module is illustrated in Figure 4-9. As shown, the load 
module consists of 14 phases divided into three regions. The OVERLAY and REGION 
control statements required to produce this structure are illustrated in Figure 4-10. If 
this same load module were defined by using only OVERLAY control statements, its 
structure would be as illustrated in Figure 4-11. 
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1, The origin of each region is the end of the jongest path of the previous region. 
2. The root phase is in the path of every region. 
3: Up to 10 regions are permitted per toad module. 


eS Figure 4-9, Program SAMPLE as a Multiregion Load Module 
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Figure 4-10. Control Stream Coding Required to Construct the Multiregion Load Module 
SAMPLE 
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Figure 4-11. Program SAMPLE as a Multiphase Load Module 


UP-8841 Rev. 4 421 





Functional Characteristics 


As can be seen by comparing Figure 4-9 with Figure 4-11, a load module constructed 
as a multiregion load module normally requires more main storage space for execution 
than the same program configured as a multiphase load module. Multiregion 
structures are most useful, however, when a need exists for 1 phase to reside in an 
area where it will not be overlaid by other phases that may not be directly associated 
with it. Also, it is sometimes possible to realize an actual saving in main storage space 
with a multiregion construction when one or more control sections are required for two 
or more distinctly separate phases, but are not required by any other phases. In this 
case, these CSECTs could be placed in a separate region, rather than being embedded 
in a phase common to the phases requiring them. Placing them in a common phase 
could unnecessarily affect the origins of succeeding phases even though the majority of 
these phases do not require these CSECTs. The opposite is true when these CSECTs 
are placed in a separate region; however, inasmuch as region origins always are 
assigned at the end of the longest path of the preceding region, unnecessary placement 
of CSECTs in separate regions may have an adverse effect on the overall length of the 
load module. 


Regions are declared by the programmer with the REGION control statement in much 
the same way a phase is declared with an OVERLAY control statement. Both 
statements initiate construction of a new phase at some symbolic starting address, or 
node point, specified in the control statement. The only difference between the two 
statements is the way they cause the linkage editor to assign an origin to the phase 
being created. Region nodes are always logical and never reference a previously 
defined symbol because a new path is about to be constructed. 


4.7. Linkage Editor Operation 
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When the linkage editor is called upon to perform its intended functions via a // EXEC 
LNKEEDT job control statement, it searches the appropriate control stream data set for 
control statement data. If control statements specifying the object modules to be 
included in the load module are found, the linkage editor links these modules together 
in accordance with the control statements that affect the structure of the load module 
that also may be in the control stream. If no control statements that identify the object 
modules to be included are found, the linkage editor links together all the object 
modules currently in the job’s run library file, as previously described. 


Under normal operating conditions (no linkage editor capabilities suppressed or 
altered), the linkage editor performs the following operations for each link-edit job: 


e Automatically includes any object modules needed to satisfy any references not 
defined in the object modules specifically included in the load module by the user 


e Automatically deletes control sections redundantly included in any non-unique 
path of a load module 


¢ Determines in what phase each common storage area is best located in the load 
module i 
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¢ Automatically includes an automatic overlay control routine and its associated 
control tables in the load module if it is required for execution of the program 


¢ Resolves multiple definition problems in the load module 


¢ Includes partial object module elements (CSECTs), if specified by the user, in the 
load module 


© Detects object modules that are marked reentrant, deletes their text, and creates 
appropriate shared records to indicate the reentrant code requirement 


© Relocates ISD records detected in object modules and passes them to the load 
modules being created 


¢ Produces CSECT/COM ISD records based on the CSECT/COM records being 
included 


The processing involved in performing these operations is described in the remainder 
of this section. 


4.7.1. Automatic Inclusion Processing 


The linkage editor is designed to automatically include object modules in a load 
module when such modules are needed to satisfy references in the object modules 
specifically included in the load module by the user. When a reference is found in a 
specifically included object module for which no definition exists, the linkage editor 
searches up to two object module library files looking for an object module containing 
the definition. 


The library files to be searched are specified by the user through the ALIB and RLIB 
keyword parameters of the // PARAM or LINKOP linkage editor control statements. If 
the definition is found, the entire object. module containing the definition is 
automatically included in the load module being constructed. If the required definition 
is not found, all references to the undefined label are flagged as errors in the link-edit 
map. All automatically included object modules are placed in the root phase of the 
load module being constructed. 


To facilitate use of the automatic inclusion feature and avoid redundant searches of 
object module files, library directories contain a cross-reference index that points to 
label definitions (CSECTs, COMs, and ENTRYs) in the object modules. These file 
directories are scanned for the required reference definitions, rather than the object 
module elements. The search for label definitions continues within the directories 
until all labels are defined or until the entire directory is scanned once without 
creating new, undefined references. All references that cannot be satisfied are flagged 
as errors in the link-edit map. 
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New, undefined references sometimes appear within an automatically included object 
module or in the object module elements introduced by INCLUDE control statements 
embedded in an automatically included object module. These embedded INCLUDE 
statements are processed in exactly the same way as INCLUDE statements embedded 
in specifically included object modules. Thus, an INCLUDE statement embedded in 
an automatically included object module could request the partial inclusion of an 
object module as well as the inclusion of a complete object module. 


All object module elements included in a load module as a result of an INCLUDE 
statement being embedded in an automatically included object module are placed in 
the root phase of the load module as part of the automatically included object 
modules. 


If a label is defined in an automatically included object module, that definition is used 
to satisfy all references to that label appearing in the load module. If a label is defined 
in a specifically included object module and a second definition of the same label is 
contained in an automatically included object module, the second definition is ignored 
by the linkage editor. If a label is defined in two or more specifically included object 
modules that are in the same phase, the first definition obtained by the linkage editor 
is used to satisfy all references to the label. These three referencing techniques are 
illustrated in Figure 4-12. 


If an automatically included object module contains a control section whose name is 
already defined by a label in a previously included object module, that control section 
is not included in the load module even if that control section contains an ENTRY 
point definition that may be required in the load module. 





Another function of the automatic inclusion feature is to construct a single-phase load 
module from all the object modules in the system job run library ($Y$RUN) when the 
linkage editor is executed and no control statements defining the load module to be 
constructed are provided by the user. 


The automatic inclusion feature can be inhibited by the user through the NOAUTO 
keyword of a // PARAM or LINKOP control statement. This capability is provided to 
enable the user to check the completeness of the definitions within his own program. 
In this instance, all references to undefined labels are flagged in the link-edit map 
without an attempt by the linkage editor to satisfy them. , 
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The arrows indicate which definition is used to satisfy each reference. 


Figure 4-12. Referencing Label Definitions in a Load Module 
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4.7.2. Automatic Deletion Processing 


The linkage editor automatically deletes control sections and ENTRY points 
previously defined in the phase currently under construction, or in a phase that is on 
the path of the current phase. When a newly included object module is found to 
contain a CSECT, or an ENTRY point with the same name as a CSECT or an ENTRY 
point previously defined, the linkage editor deletes the second definition from the 
phase under construction. Unlabeled control sections are not automatically deleted 
because each of them is considered a unique entity for lack of a name. Shared 
definitions are considered to be in the root phase, so any subsequent duplicate 
definitions will always be deleted. However, nonshared definitions that are accepted 
before a shared definition is encountered are not deleted. Also, if such definitions are 
themselves in the root phase, they will cause the automatic deletion of all subsequent 
definitions, shared or unshared. 


The only exception to this rule for automatic deletion is when multiple CSECTs are 
found to have the same name as a labeled common storage area. In this instance, the 
CSECTs are treated as block data subprograms and are used to initialize the 
associated common storage area. These multiple CSECTs, however, must be included 
in the load module after the inclusion of the related common section; otherwise, the 
second and subsequent CSECTs could be deleted automatically. Common (COM) 
sections in reentrant object modules are treated as DSECTs. In nonreentrant object 
modules, unnamed COM sections are never deleted. Deletion of named COM sections 
is subject to the rule that block data/common relations are not permitted across 
nonreentrant/reentrant code boundaries. Thus, if a shared CSECT has been accepted 
and, subsequently, a nonshared COM with the same name is encountered, the COM 
section is deleted. On the other hand, if a nonshared COM section has been accepted 
and a subsequent shared CSECT with the same name is found, the CSECT is deleted. 


Thus, if a second definition for a name already defined on the path of the current 
phase is detected, the second definition is ignored. A single-phase program, therefore, 
will contain only one definition for each label that does not match a common section 
name. Only one definition is accepted, even if the subsequent definition is for an 
absolute entry. All absolute entry items are treated as low-priority items and are 
always deleted whenever at least one duplicate definition exists in the load module. 


4.7.3. Common Storage Processing 


4-26 


The linkage editor constructs a common storage area for each unique COM section 
contained in a load module. COM sections with the same name, however, are assumed 
to be referring to the same common storage area; therefore, the linkage editor creates 
a single common storage area for these COM sections. The size of each storage area is 
equal to the largest size requested by all object module elements referring to a COM 
section. Thus, if one object module indicates that COM section A requires 256 bytes of 
main storage, and another object module indicates that COM section A requires 1,024 
bytes of main storage, the linkage editor creates a single common storage area of 1,024 
bytes to satisfy all object module references to COM section A. Blank (unlabeled) 
common storage is allocated in the same way. 
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The linkage editor assumes that the following rules concerning COM section 
specification have been adhered to by the object module element programmer. 


e An ENTRY point in a load module cannot bear the same name as a labeled 
common storage area included in the load module. 


¢ When a phase containing a CSECT with the same name as a common storage 
area is loaded for execution, that section is treated as a block data subprogram 
and is loaded in all or a portion of the common storage area with the same name. 
(Block data subprograms can be used to initialize common storage areas. Blank 
common storage areas cannot be initialized during loading unless the text 
following the common storage area declaration is for that COM ESD.) 


¢ All COM sections defined in an object module are processed by the linkage editor, 
even if only a partial INCLUDE of an object module is taking place and the 
included object module element does not refer to any common storage area. 


¢ COM sections encountered in reentrant object modules are treated as DSECTs. 
They do not result in any space allocation during the creation of a reentrant load 
module. 


¢ Automatic deletion of nonshared common sections is subject to the rules 
established for deletion processing. 


In the past, most linkage editors placed all common storage areas in the root phase of 
all load modules, regardless of the structure of the phases requesting access to the 
common storage area. This allocation scheme forces all phases of a load module to 
include the space required by all common storage areas in their main storage space 
requirements, even if they do not use any common storage space. The OS/3 linkage 
editor, however, is designed to promote the allocation of common storage areas. The 
promotion of a common storage area refers to its placement within a nonroot phase 
segment of a load module. The OS/3 linkage editor allocates common storage areas 
only as required by the structure of the phases referencing them. 


Figure 4-13 illustrates a load module in which a common section was promoted. As 
shown, common storage areas A, B, and C are located in the root phase because they 
are referenced by phases whose only common phase is the root phase. But, because 
common storage area D is referenced only in phases 2 and 3, it was promoted to the 
phase 1 segment because this segment also is common to both phases. In this way, 
phases 4, 5, and 6 do not need to pay for the storage space required by common section 
D because it will be loaded only when phase 1 is loaded. Thus, this promotion 
technique allows a load module to require less main storage space then would 
otherwise be required. It should be noted, however, that common storage area D is 
overlaid each time phase 4 is loaded, and the use of common storage area D must be 
planned carefully by the programmer to ensure that required common storage area 
data is not overlaid before that data is processed. Nonroot phase common sections 
normally are feasible only when phased programs are executed in a straightforward 
fashion. For example, if phases 2 and 3 of Figure 4-13 were executed consecutively, 
followed by the execution of phases 4, 5, and 6, in that order, and the program was 
concluded without ever having to repeat either phases 2 or 3, common section D would 
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probably fit very nicely in phase 1. On the other hand, if phase 2 were executed and 
stored data in common section D for use by the phase 3 program segment, but the 
phase 4 program segment was loaded next, the common storage data for the phase 3 
program would be overlaid and its data rendered useless to the subsequent execution 
of the phase 3 program segment. 


PHASE 0 
(ROOT PHASE) 













PHASE 1 


PHASE 2 





COMMON 
SECTIONS 
PHASE 3 
Dp 
PHASE 4 
R 
c PHASE 5 
R B 
PHASE 6 

LEGEND: Ra 
D Definition of a common storage area 
R Reference to a common storage area 


Figure 4-13. Example of Common Storage Promotion Scheme 


This capability of the linkage editor can be enabled and disabled through the PROM 
and NOPROM keyword parameters of the // PARAM and LINKOP control statements. 
Thus, to inhibit the promotion and force root phase assginment of common storage 
areas, the user need only specify the NOPROM keyword in his input control stream to 
the linkage editor; otherwise, the promotion of common storage is enabled. 
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4.7.4. Automatic Overlay Control Processing 


The linkage editor can automatically load the various phases of a multiphase or 
multiregion load module in main storage in accordance with the execution 
requirements of the program. Normally, the loading and execution of the phases of a 
program is done by the programmer through the object code in each phase of the load 
module. If the programmer wishes, however, he may leave this responsibility up to the 
linkage editor for the minor cost of the storage space required to include the automatic 
overlay control routine and its associated control tables in his load module. The exact 
amount of storage varies with the number of control table entries required to describe 
the load module. 


When the programmer wishes to have his program phases loaded automatically, he 
must reference the ENTRYs he wishes to transfer control to with V-CON (type V 
address constants) references. Then, when he proceeds to link-edit his program as 
either a multiphase or multiregion load module, the linkage editor decides whether 
the automatic loading of phases is required based on 


¢ The types of EXTRNs (type A or type V) contained in the object modules being 
included in the load module 


¢ The types of references (inclusive or exclusive) in the load module 
¢ The V-CON processing option, if in effect (V-CON processing is normally enabled) 


& If the V-CON processing option is in effect and at least one exclusive V-CON reference 
is in the object code being included in the load module, the linkage editor constructs a 
set of tables depicting the load module structure and includes them in addition to an 
automatic overlay control routine in the root phase of the load module. Also, the 
linkage editor modifies the V-CON references in the load module to make them 
reference the automatic overlay control routine. The automatic load routine (KL$OCP 
or KL$OCPR) that is copied into the load module depends on the number of regions 
comprising the load module. The KL$OCPR routine is capable of handling the 
automatic overlay requirements of a multiregion load module; KL$OCP is not. 


When a load module containing the automatic overlay facilities is executed, its root 
phase is loaded in main storage, as is any other load module, by the supervisor, and 
program control is transferred to the program ENTRY point for the phase. As program 
execution proceeds, V-CON references cause the needed phases to be loaded, thus 
satisfying the type V address constant that referenced the label of the required entry 
point. A branch instruction is executed through register 15, forcing transfer of control 
to the overlay control routine because the type V address constant was previously 
modified by the linkage editor to reference the routine. The automatic overlay routine 
then checks to see if the required phase is in main storage. If it is, the overlay control 
routine branches directly to the proper address. If it is not, the automatic load routine 


® Determines the phases currently in main storage 


* Loads the required phase, and any phase on the path of the required phase, into 
® main storage 
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¢ Records the new path as loaded 
e Branches to the proper address 


The overlay control routine executes LOAD macroinstructions as needed to obtain the 
required phases and records this information in its control tables. The path 
information is examined by subsequent invocations of the automatic overlay control 
mechanism and is altered if additional phases are loaded. Attempts made by the 
problem program to load phases directly do not cause an update of the path 
information; therefore, you would not issue any LOAD, LOADR, or FETCH 
macroinstructions in your problem program using the automatic overlay control 
routine. 


The type V address constant in register 15 for the automatic loading of overlays has 
the following characteristics: 


¢ It always occupies 4 bytes; the entire word is reserved for use by the linkage 
editor. Byte 0 of this word contains a number (zero or greater) that is an index 
into the list of NTAB entries. Bytes 1 through 3 consist of the address of the entry 
point table; however, a V-CON may have all zeros. 


¢ Itis intended for branching only and may not be used for addressing data. Data 
references do not cause the referenced phase to be loaded automatically, because 
transfer of control is essential for the process to be effective. 


e When a type V address constant addresses a definition that is on the same path 
as the reference, the constant is treated as though it were a constant of type A. If 
such a constant is in register 15, the problem program branches directly to the 
required location, rather than transferring control to the overlay control 
mechanism. 


The data required by the automatic overlay control routine to perform these functions 
is contained in its associated control tables. Brief descriptions of the components of the 
automatic overlay mechanism follow. 


Overlay Control Routine 


The overlay control routine is a program used for the automatic loading of segmented 
program structures. It is responsible for loading the program segments (phases) and 
maintaining the tree structure of the program. It supplies the needed interface and 
controls to allow the user to use segmentation without difficulty. It also causes 
automatic loading of the needed program phases as determined by exclusive V-CON 
references. An automatic ENTRY point (KL$OCP) always is supplied to allow 
references to the standard automatic overlay control routine. A second routine 
(KL$OCPR) is used if the load module structure comprises multiple regions. The 
control routine is always placed in the root phase of a load module and is entered 
through the entry point table. ; 
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Entry Point Table (NTAB) 


The NTAB table also is always in the root phase. It front-ends the overlay control 
routine and contains such control information as the path being automatically loaded, 
where the phase is being loaded (or its relative position in main storage), and a list of 
entry points corresponding to the V-CON definitions in the problem program. The 
NTAB determines the phase to be loaded when a V-CON reference refers to a phase 
not in the same path as the reference. An NTAB entry is not created for any V-CON 
symbol already present in a phase higher in the current path (closer to the root phase). 
An automatic entry point (KL$NTB) always is supplied to allow references to NTAB. 


Phase Table (PTAB) 


The phase table contains information concerning the relationships between the phases 
of the load module. Only one phase table is built for any multiphase load module that 
requires automatic loading, and it is always in the root phase. An automatic entry 
point (KL$PTB) always is supplied to allow references to PTAB. 


Region Table (RTAB) 


The region table is generated only for load module structures using V-CON references 
in which multiple regions are involved. It describes the number of regions making up 
the load module and the highest phase contained in each region. The RTAB is used in 
conjunction with NTAB and PTAB, plus the region overlay control routine 
(KL$OCPR), to manage V-CON references in load modules with two or more regions. 
An automatic entry point (KL$RTB) always is supplied to allow references to RTAB. 


4.7.5. Multidefinition Resolution Processing 


The multidefinition resolution processing performed by the linkage editor depends on 
the type of definition being referenced. 


Standard (Non-V-CON) References 


If the user references a definition with a standard reference and the definition being 
referenced is not on the path of the reference, he is required to issue the appropriate 
supervisor FETCH and LOAD macroinstructions to ensure that the phase containing 
the proper definition is loaded when the definitions it contains are referenced. (The 
linkage editor allows standard EXTRN-ENTRY relationships to occur across phases 
without any special processing when V-CONs are not involved.) 


Because of the automatic deletion mechanism of the linkage editor, only one definition 
will ever be present on each path of a load module. If a definition is present in the root 
phase, no identical definitions will be in other phases unless the path involved 
overlays the root phase entirely. 
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If there is only a single definition for a reference, the linkage editor obtains the 
appropriate phase number and value for the definition and applies it accordingly. But, 
when a reference is marked as being multiply defined, each phase number assigned to 
each definition is, in conjunction with the segment table, used to determine the 
relationship between definitions and references. The linkage editor then satisfies the 
reference in accordance with the following logic: 


a. 


If a definition that satisfies a reference is in the same phase as the reference, the 
linkage editor uses it to satisfy the reference. 


If a definition that satisfies a reference is on the path of the reference, the linkage 
editor uses it to satisfy the reference. 


The linkage editor determines if the reference is on the path of one or more 
definitions that can satisfy the reference. If it is, the linkage editor chooses the 
first definition following the reference to satisfy the reference. 


The linkage editor chooses the first definition following the reference (higher 
phase number), regardless of path associations, to satisfy the reference if one 
exists. 


The linkage editor uses the first backward definition (lower phase number) to 
satisfy the reference. 


These five reference-definition relationships are illustrated in Figure 4-14. Further, 
wherever the linkage editor must satisfy a reference in accordance with c, d, or e, it is 
indicated on the link-edit map. 
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io) Definition (E) 
R Reference 
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Figure 4-14. Multidefinition Resolution without V-CON References 
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V-CON References 


The resolution processing for V-CON references is much the same as that for standard 
references, except that 


e AV-CON reference may be converted to an A-CON reference. 
¢ AV-CON reference forces control to the automatic overlay control mechanism. 


¢ Exclusive V-CON references do not initiate diagnostic messages. 


© AV-CON reference resolved to a shared definition is converted to an S-CON 


(shared constant). 


Thus, at resolution time, multiple definitions for any referenced symbol are handled 
as follows: 


1. Ifa definition is on the path of the reference, that definition is selected by the’ 
linkage editor to satisfy the reference. (Only one inclusive definition is possible.) 


2. Otherwise (definition is exclusive of the reference), the first forward definition is 
chosen by the linkage editor if one exists. If none exist, the first backward 
definition is chosen. 


When an object module incorporating V-CONs is being included, V-CON processing 
will include the following. Whenever a V-CON reference occurs, the linkage editor 
keeps track of the first such reference since the last definition. For multidefined 
V-CONs, separate NTAB entries may be constructed, as references are assigned to 
different definitions of the same symbol. This selection of definitions is a function of 
where the appropriate references occur with respect to path relationships concerning 
those definitions. 


Multidefinition V-CON processing occurs 


a. Ifa V-CON definition is on the path of the V-CON reference (or references), that 
reference will be treated as a direct A-CON reference and will be flagged. 
accordingly. 


b. Ifa V-CON reference is on the path of a V-CON definition, it is a valid V-CON 
reference. 


ce. Ifa V-CON reference is on the path of multiple definitions, the automatic 
deletion mechanism will eliminate the subsequent definitions (where such 
definitions are contained in the same path or phase) and the first definition will 
be used to satisfy that reference. 


d. IfV-CON references and multiple definitions exist on separate paths, the first 


forward definition will be used if there is one; otherwise, the first backward 
definition is used. , 
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If V-CON references and multiple definitions are on separate paths but in the 


e. 
same direction (forward or backward), the first definition encountered is used. 


These five reference/definition relationships are illustrated in Figure 4-15. 







PHO 
D PH1 
R 
A-CON 
PH2 
A-CON ~R 
(A) 
AUTOMATICALLY 
DELETED 
DEFINITION 
(c) 
PHO PHO 


AUTOMATICALLY 
DELETED 
DEFINITION 





(D) (E) 


LEGEND: 
PH Phase 


D Defnition 
R Reference 


Figure 4-15. Multidefinition Resolution with V-CON References 
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4.7.6. Partial INCLUDE Processing 


The linkage editor can include only specific CSECTs of an object module in a load 
module, if the user so desires. These CSECTs are specified by the user in INCLUDE 
control statements that contain a CSECT name list as its second operand, as well as 
the name of an object module as its first operand. Up to nine control sections can be 
specified in any one INCLUDE statement. 


When CSECTs are specifically referenced in an INCLUDE statement, they are 
inserted in the load module in the order that they appear in the object module, 
regardless of the order in which they are specified in the INCLUDE statement. The 
rearrangement of CSECTs in a load module, however, can be accomplished by 
multiple INCLUDE statements, each of which references only a particular CSECT. In 
this way, the INCLUDE statements can be arranged to cause the resulting load 
module CSECT structure to assume any form desired. The smallest segment of object 
code that may be included in a load module is a CSECT. 


Whenever an object module is accessed for a partial inclusion of its elements, any 
control statements that may be embedded in the object module are processed by the 
linkage editor as standard, embedded control statements, and any common sections 
defined in the object module are included in the load module. 


4.7.7. Shared Code (Reentrant Code) Processing 


4:36 


Shared or reentrant code is a piece of code that is not self-modifying. Thus, a number 
of programs can call upon a single copy of this code and run concurrently. Sharing code 
effectively reduces the main storage requirements of the system. Consider two 
programs, X and Y, that call upon a reentrant routine, Z. It is obvious from Figure 
4-16 that sharing Z allows both programs to be executed in less main storage space 
than would otherwise be required. 


The librarian is capable of marking object modules reentrant by setting a flag in the 
object module header record. Unless otherwise marked, object modules are 
nonreentrant. The flag can be turned on or off by the librarian RENAME control 
statement. 


It is the responsibility of the linkage editor to detect reentrant object modules, delete 
their text, and create the appropriate interfaces to enable linkages to be established at 
execution time. This feature can be enabled or disabled through options on // PARAM 
or LINKOP cards. 


Since the reentrant code itself does not appear in the load module produced, it must 
be link-edited separately. This is done in a special mode of the linkage editor through 
// PARAM-LINKOP cards. 
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SITS 


MAIN STORAGE MAIN STORAGE 


ee eee et ee 


PROGRAM X PROGRAM X 


ROUTINE Z 
PROGRAM Y 






















MAIN 
STORAGE 
MAIN REQUIRED 
STORAGE 
REQUIRED PROGRAM Y - 
ROUTINE Z 
ROUTINE 2 
FREE SPACE 
a. Nonsharing environment b. Sharing environment 
@ Figure 4-16. Effect of Shared Code on Main Storage Requirements 


Thus, there are three processing modes controlled by // PARAM-LINKOP options: 


1. Normal link-edit with no recognition of reentrant object modules (NOSHARE, 
NORNT options). 


2. Link-edit with sharing capability enabled (SHARE option). 


3. Link-edit of a reentrant module by itself (RNT option). 


Share Facility 


The linkage editor detects reentrant object modules under either of the following 
conditions: 


1. An INCLUDE control statement was supplied that referenced a specific object 
module which, when located, was found to be marked reentrant. 


2. Asaresult of an unresolved EXTRN reference in the user module being link- 
edited, the automatic INCLUDE mechanism was triggered. When the definition 
was detected, the object module containing the definition was found to be marked 
reentrant. 
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Provided that the share processing facility is enabled, the linkage editor, upon @ 
encountering the reentrant object module, performs the following: 


1. The text from the object module (or part, if partial INCLUDE) is dropped and 
does not contribute towards the load module being produced. 


2. The CSECT and COM lengths in the object module are not reflected in the load 
module size. 


3. COM sections and ISD records are ignored. 


4, All ESD items (except COMs) are entered into the linkage editor’s internal 
symbol table and are processed normally. 


5. Shared definitions (definitions encountered in the reentrant object module) are 
treated as if they occurred in the root phase and are subject to automatic deletion 
processing rules. This includes block data/common conflicts between reentrant 
and nonreentrant.code. 


6. Aspecial record (the resource record) is created in the load module. This record 
contains the name of the object module. At program execution time, it informs job 
control of the requirement for a resource, namely the reentrant module. 


Satisfying shared resource requirements is a part of the total job scheduling process 
and is performed before actual program execution begins. 





Linkage in Shared-Code Environment 


In the course of a link-edit with the share facility enabled, the linkage editor 
distinguishes between the different types of EXTRNs as shown in Figure 4-17. As is 
obvious from Figure 4-17, reentrant code cannot call nonreentrant code. 


Each SEXTRN causes the creation of a SEXTRN record in the load module. This 
record contains the SEXTRN name and a unique number assigned to the SEXTRN 
called the SINDEX number. The SEXTRN record is used to link the load module with 
the reentrant code at execution time. 

EXTRN Found 


Resolved Nonreentrant . 
in] to —> Object Module 
Nonreentrant object Allowed normal 
module EXTRN 


Not allowed unless 
the definition is 
absolute 










Reentrant 
Object Module 






Allowed SEXTRN 
(shared EXTRN) 





Allowed provided 
requirements in 
4.7.7 are met 


Reentrant object 
module 







Figure 4-17. EXTRN Resolution Processing in Shared-Code Environment 
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Shared Constants 


Type A or type V address constants associated with SEXTRNs are known as shared 
constants (S-CONs). You can transfer control to shared code by loading such a 
constant into register 15 and branching to it. Only type 1 linkages are allowed for calls 
from nonreentrant to reentrant code. Register 13 must be loaded with the address of 
an 18 full-word save area. 


The shared constant in register 15 has the following characteristics: 


1. It always occupies 4 bytes; the entire word is reserved for use by the linkage 
editor. Byte 0 of this word contains an index (called the SINDEX (shared INDEX) 
number), which is a unique number for every SEXTRN. Bytes 1 through 3 consist 
of the address of the preamble SEXTRN processor. This address is negative since 
the SEXTRN processor resides in the prologue. 


2. Itis intended for branching only and may not be used for addressing data. The 
SEXTRN processor, after receiving control, converts the SINDEX number into an 
absolute address and branches to it. It uses the save area and user registers for 
its own housekeeping, and then restores them before branching to reentrant code, 
which must have its own mechanism for saving registers if it needs to. 


3. It must be coded as a symbol, not as an expression. For example, V(X) and ACY) 
(where Y is declared as an EXTRN) are valid shared references, V(X+4) is not. 


Link-Editing Reentrant Code 


In order for reentrant code to be loaded, it must be link-edited. This is done in a 
special mode of the linkage editor (RNT option on // PARAM-LINKOP cards). The 
link-edit of reentrant code has the following special characteristics: 


1. No overlay structures are permitted. 
2. The load module name may be up to eight characters long. 


3. COM sections are treated as DSECTs. No storage allocation is performed for 
them. 


4. For each relative definition (CSECT, ENTRY, linkage editor EQU), a SENTRY 
record is created in the load module. This record informs job control at execution 
time that a definition is available in the module and can be used for establishing 
linkages. No SENTRY record is produced for absolute ENTRYs and EQUs. The 
relative definitions are known as SENTRY (shared ENTRY) items. 


5. Only specific INCLUDEs are meaningful and the text encountered during the 
specific INCLUDE process contributes to the load module. All references in the 
included object modules must be inclusive; that is, the reentrant load module 
must be self-contained. Option NOAUTO should be in effect during the course of 
the link-edit. 
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6. All address constants must be absolute. The code must relocate them, if @ 
necessary. 


7. Normally, only one reentrant object module would be specifically included. The 
linkage editor will permit more than one reentrant object module to be 
specifically included provided the user program directly references only one of the 
object modules being included. Stated another way, there must be only one object 
module that is at the highest level of the intercalling sequence within the group of 
reentrant object modules being included. The name on the LOADM control 
statement must be the same as the name of the highest level reentrant object 
module. 


8. The reentrant load module must be output on the system load library ($Y$LOD). 


9. The ISD records in the object module are ignored. 


Shared Records 


The linkage editor creates special records in load modules that reference reentrant 
code and also in the reentrant load module. These records provide information on 
linkages to be established and the reentrant modules that are required. 


The format of a nonreentrant user load module that references reentrant modules is 
shown in Figure 4-18. A flag is set in the phase header record indicating that shared 
code is referenced. For each reentrant module referenced, a resource record is 
produced. This record contains the name of the reentrant load module and a unique 
number called the resource number. For each EXTRN in the user module resolved to a 
definition (CSECT/ENTRY) in the reentrant module, a SEXTRN record is produced 
containing the CSECT/ENTRY name and number of the resource that contains the 
definition. If an EXTRN is resolved to an ENTRY which has the same location as its 
CSECT, the reference is considered being made to the CSECT. Therefore, the 
SEXTRN record contains the CSECT name rather than the ENTRY name. However, 
several SEXTRN records can be created for each resource record depending upon the 
number of definitions referenced in the resource (reentrant object module). If the user 
module references other reentrant modules, additional sets of resource and SEXTRN 
records will be created. 





The format of a reentrant load module is shown in Figure 4-19. The phase header is 
marked with a flag indicating that it is a reentrant load module. Relative definitions 
(CSECTs, ENTRYs, and EQUs) detected in your link-edit are called SENTRY (shared 
ENTRY) items and produce SENTRY records. However, a SENTRY record is not 
produced for a COMMON, an absolute ENTRY, an absolute EQU, or a relative 
ENTRY at the same location as its CSECT. A SENTRY item contains the SENTRY 
name, its link origin, and a unique number called the SENTRY number. No ISD 
records are produced in a reentrant load module. See Table B-18 for the format of a 
SENTRY record. 
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PHASE HEADER RECORD (ROOT PHASE) 


RESOURCE RECORD 


SEXTRN RECORDS ASSOCIATED WITH THE RESOURCE 


SETS OF RESOURCE AND SEXTRN RECORDS 


ISD RECORDS 


TEXT RECORDS 


TRANSFER RECORD 





PHASE HEADER RECORD (PHASE 1) 


a a ey 


SETS OF PHASE HEADER, TEXT AND TRANSFER RECORDS DEPENDING UPON 
THE NUMBER OF PHASES IN THE LOAD MODULE. 


Figure 4-18. Format of a Nonreentrant Load Module that References Shared Code 
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PHASE HEADER RECORD (ROOT PHASE) 
SENTRY RECORDS 
TEXT RECORDS 


TRANSFER RECORD 


Figure 4-19. Format of a Reentrant Load Module 
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When the user load module is executed, its resource and SEXTRN records are 
examined to determine reentrant code requirements for the module. An attempt is 
made to resolve SEXTRNs against reentrant code already loaded. If the required 
reentrant code is not already loaded, $Y$LOD is searched for the modules named in 
the resource records. 


When a required module is found, a match is attempted between the SEXTRNs in the 
user module against the SENTRYs in the reentrant load modules. Linkages are then 
established based upon the matches, and the appropriate reentrant modules are 
loaded. Shared constants themselves remain unchanged. Satisfying shared resource 
requirements is a part of the total scheduling process and is performed before actual 
program execution begins. 


Consider the following example. A user object module USER has external address 
constants R2 and T1 and a type V address constant T3. A reentrant object module R1 
exists with CSECT R1 and ENTRY points R2 and R3. Another reentrant object 
module, T1, has CSECTs T1 and T2 and entry point T3. Figure 4-20 depicts the 
outputs of the link-edits of USER with the NOSHARE and SHARE options specified, 
and the link-edits of Rl and T1 with the RNT option specified. Note that, in b, no 
SEXTRN records were created for CSECTs R1 and T2 or ENTRY R3. This is because 
USER does not require these definitions to satisfy any of its external references. 


4.7.8. Internal Symbol Dictionary (ISD) Processing 
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The internal symbol dictionary (ISD) records describe user program symbols. These 
records can appear in either object or load modules. When the ISD records appear in 
object modules, they are generated by certain language processors; while in load 
modules, the linkage editor generates them. 


As just mentioned, the ISD records are used as descriptor records and, therefore, do 
not increase the size of the object or load module. When they appear in a load module, 
they are not loaded with the records at execution time, so no additional main storage 
is required. However, the ISD records do play an important role if your program has 
an abnormal termination and the JOBDUMP option was specified on the OPTION job 
control statement. In this case, JOBDUMP reads the ISD records in the load module 
and does the following: 


e Prints the dump segmented by the CSECTs of the user program. 


¢ Prints the user-defined symbols and tables. The dump produced is formatted and 
will include compile and link origins, source line number of the symbol, data type, 
and value. 


You can inhibit the generation of ISD records in your load module by using the linkage 
editor option NOISD on the // PARAM-LINKOP control statement. If you inhibit the 
ISD record generation and an abnormal termination occurs in your program, then 
JOBDUMP will produce an unformatted dump of the load module area. 
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PHASE HEADER RECORD FOR USER 





TEXT RECORDS (OBJECT CODE FROM USER, R1 AND T1) 





TRANSFER RECORD 





a. USER with NOSHARE option specified 





PHASE HEADER RECORD FOR USER 





RESOURCE RECORD FOR R11 


SEXTRN RECORD FOR R2 





RESOURCE RECORD FOR T1 
SEXTRN RECORD FOR T1 
SEXTRN RECORD FOR T3 


TEXT RECORDS (OBJECT CODE FROM USER) 





TRANSFER RECORD 





b. USER with SHARE option specified 





PHASE HEADER RECORD FOR R1 





SENTRY RECORD FOR R1 


SENTRY RECORD FOR R2 





SENTRY RECORD FOR R3 





TEXT RECORDS (OBJECT CODE FROM R1) 





TRANSFER RECORD 





c. R1 with RNT option specified 


PHASE HEADER RECORD FOR T1 


SENTRY RECORD FOR T1 


SENTRY RECORD FOR T2 


SENTRY RECORD FOR T3 


TEXT RECORDS (OBJECT CODE FROM T1) 


TEXT RECORDS (OBJECT CODE FROM T2) 


TRANSFER RECORD 


d. T1 with RNT option specified 


Figure 4-20. Link-Edit Output 
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Object ISD Records 


The object ISD records are generated in your object module by certain language 
processors. The linkage editor processes these records so that if an abnormal 
termination occurs while executing your load module, JOBDUMP can give you a 
formatted dump displaying user program symbols and their attributes. There are two 
types of object ISD records. 


¢ Type 3 ISD record 
This record describes user-defined and compiler-generated symbols. The Type 3 
record contains information such as: symbolic name, source line number of the 
symbol, level number, data type, and compile origin of the symbol. 

° Type 4 ISD record 
This record contains English text and is used by JOBDUMP to print titles and 
headings in the dump. 

Load ISD Records 

The load ISD records are generated in your load module by the linkage editor 


provided the ISD option on either the // PARAM or LINKOP control statement was 
specified. The ISD record generation is based on the following: 





e The presence of object ISD records in the object module. The linkage editor 
relocates their addresses and passes them into the load module. 


¢ CSECTs/COMMONS accepted during the link-edit job. 


e ISD records are not produced for the link-edit of a reentrant load module (RNT 
parameter). 


¢ Ifyou specified the SHARE parameter, the object ISD records in an included 
reentrant object module are ignored. Also, CSECTs and COMs in the reentrant 
object module do not result in the generation of either Type 1 or Type 2 ISD ; 
records. 


¢ Deleted CSECTs or COMs do not contribute toward the generation of load ISD 
records. 


¢ Object ISD records belonging to deleted CSECTs or COMs are ignored. 





444 UP-8841 Rev. 4 








Functional Characteristics 





There are four types of load ISD records: 
¢ Type 1 ISD record 


This record describes a CSECT. It contains the CSECT name, compile and phase 
relative origins, size, and phase number. 


¢ Type 2 ISD record 


This record describes a COMMON section. It contains the COMMON name, 
compile and phase relative origins, size, and phase number. 


e Type 3 ISD record ; 

This record is the relocated form of the Type 3 object ISD record. 
e Type 4 ISD record 

This record is the relocated form of the Type 4 object ISD record. 
These records are not loaded at execution time, and are only used if an abnormal 
termination occurs in your program. JOBDUMP, if specified, uses the Type 1 and 
Type 2 ISD records to segment the dump by CSECT and COMMON sections. 
JOBDUMP uses Type 3 and Type 4 ISD records to print user program symbols and 

& values converted to their proper data types. 
4.7.9. User Program Switch Indicator (UPSI) Setting 

The linkage editor prints the UPSI byte settings along with the error count at the end 
of the link-edit map. When external references remain unresolved, the linkage editor 
sets the UPSI byte to X‘20’. Also, when the linkage editor issues an error message, the 


UPSI byte is set accordingly. The linkage editor error messages are found in the 
System Messages Reference Manual (UP-8076). 
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Section 5 
Programming Considerations 


5.1. Introduction 


Because the allocation of main storage is a primary concern in a multiprogramming 
system, the problem programmer should always consider the advantages of having the 
linkage editor construct this program either as a multiphase or multiregion load 
module. Further, he should consider this aspect of his program before he begins to 
code it because the use of certain object code facilities, such as common storage 
sections, enhance the ability of a program to be structured. 


This section concerns itself with the considerations involved with structuring a load 
module. The most important factor in the construction of a load module is how its 
object code segments are coded, and whether these segments take advantage of the 
capabilities of the linkage editor. — 


5.2. Overlay Structures and Dependencies 


Programs can be overlaid to minimize their main storage requirements. The 
possibility of constructing an overlay program depends on the relationships between 
the various control sections and phases to be created. These can overlay each other 
only if they do not need to be in storage at the same time and do not reference each 
other, either directly or indirectly. 


The phase segments of an overlay program must be organized in an overlay tree 
structure. The following factors should be considered when organizing the tree 
structure of a load module: 

e Phase and control section dependency 

¢ Length of the multiphase program 

e Frequency of usage of each control section 

¢ Possibility of using separate overlay regions 

To begin building an overlay structure, the user should first form a root phase that 
contains the modules that will receive control from the start of execution and those 


which should always remain in main storage. The rest of the structure should then be 
developed in accordance with the information presented in the following paragraphs. 
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5.2.1. Phase Dependencies 


Whenever a phase is in main storage or is being loaded in main storage, all the phases 
in its path also should be in main storage. Phases may be loaded in any sequence 
whatsoever and reloaded any number of times, as required by the logic of the program. 
The assigned location of the phases has no bearing on the order in which the phases 
are executed. Any part of a phase that is modified during its execution will remain so 
only until the phase is overlaid. 


5.2.2. Control Section Dependencies 


A control section can receive control from another control section, but both sections 
must be in main storage before execution can continue beyond a given point in the 
program. The requirements of a control section for a given routine in another control 
section determine such dependency. Conversely, that control section is dependent 
upon any other control section from which it can receive control or where the other 
section has a need to process the former section’s data. 


5.2.3. Program Length 


The length of a multiphase program must be considered by the user in the 
construction of his program. The length of the longest path is the minimum storage 
requirement for a multiphase program. Also, when a program is constructed with the 
automatic overlay mechanism, the storage requirements of the necessary control 
routine, entry table, phase table, and possibly region table also must be considered. 


5.2.4. Phase Origins and Node Points 


The origin of the initial, or root phase, segment is assigned by the linkage editor at 
zero. The relative node point of each phase is determined as zero plus the length of all 
phases in the path. The characteristics of the first symbol in the operand field of an 
OVERLAY statement designate the phase origin and node point. 


5.2.5. Use of Multiregions 


5-2 


Multiregion structures can, in certain instances, capitalize on loading efficiency and 
realize a saving in main storage space. Phases not on common paths can access each 
other and, where identical copies of one or more CSECTs are required at different 
times by different exclusive overlays, they may reside in a separate region not affected 
by the path loading in the opposite region. Region structures also will decrease main 
storage needs when the creation of a common inclusive phase is not feasible or 
possible without increasing the length of the longest path of the current region. Such 
structures can provide a useful and convenient method of load module structuring 
where such concerns are paramount. 
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Programming Considerations 


Figure 5-1 illustrates a program whose structure as a multiregion load module results 
in a saving of main storage space, given the phase and CSECT dependencies noted in 
the illustration. As shown, if CSECTs F, G, and J were root phase resident, the load 
module storage needs would increase because these CSECTs could no longer overlay 
each other. 
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NOTES: 
Assumed program logic dictates the following: 


1. Phases 1, 2, and 3 can overlay each other. 
2. Phases 1 and 3 require CSECTs F, G, and J. 


3. Phase 2 requires CSECT J. 


Figure 5-1. Example of a Program Structured as a Multiregion Load Module 
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Programming Considerations 


Creation of two additional phases in region 1, each containing the exclusive CSECTs, @ 
would not appear possible because a path conflict would be created. Thus, the region 
structure shown is more feasible. 


If CSECTs F, G, H, I, and J were required by phases 1, 2, and 3, and if they were 
required at the same time, such that they could not be overlaid, root phase residence 
would be practical. 


If CSECTs F, G, H, and I were needed by phases 1 and 2, and CSECT J only needed 
by phase 3, another common node point and phase could be constructed in region 1. In 
this case, a second region, as shown in Figure 5-1, would adversely affect the amount 
of storage required for the load module. 
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Section 6 
Control Statements 


6.1. Introduction 


The linkage editor control statements described in this section direct the construction 
of a load module for OS/3 from specific or implied object modules and object module 
elements. Linkage editor control statements normally appear in an OS/3 job control 
stream, as illustrated in Figure 6-1. However, linkage editor control statements also 
may be contained in a source module or embedded (nested) in the object modules 
called by the linkage editor INCLUDE control statements. The rules for coding and 
embedding linkage editor control statements follow. 





Linkage editor contro! statements comprising 
linkage editor control stream 


/* 


Figure 6-1. Typical Linkage Editor Control Stream 


6.2. Coding Format 


The general format of a linkage editor control statement is shown in Figure 6-2. The 
label field begins in column 1, is terminated by a blank column, and may contain up to 
eight alphanumeric characters. The label field is blank for all linkage editor control 
statements except the equate (EQU) statement. The operation field must be preceded 
and followed by at least one blank column, and contains the operation code of the 
function to be performed. If the label field is blank, the operation field may start in 
column 2. The operand field begins with the first nonblank character following the 
operation field, is terminated by a blank column, and cannot extend beyond 

column 71. 


The operand field may contain any number of operands, depending on the function to 
be performed, and operands must be separated by commas. Continuation statements 
are not allowed. 
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Figure 6-2. General Linkage Editor Control Statement Format 


Comment statements, identified by an asterisk in column 1, may appear anywhere in 
a linkage editor control stream. Comments do not initiate any processing by the 
linkage editor but are printed out on the process map portion of the link-edit map. 


6.3. Placement of Control Statements 


In keeping with their functional uses, the following guidelines apply to the placement 
and sequencing of control statements: 


¢ ALINKOP, LOADM, OVERLAY, or REGION control statement may be followed 
by an INCLUDE, EQU, MOD, or RES statement. 


e An INCLUDE statement must be followed by at least one object module header 
record, and may then be followed by any number of embedded control statements, 
followed by a transfer record and, again, any number of embedded control 
statements. Any linkage editor control statement may then follow the INCLUDE 
statements. 


e An ENTER statement may not be followed by an INCLUDE statement. 


e The LOADM statement normally is the first control statement in a control 
stream. 


¢ The ENTER statement normally is the last control statement in each phase of a 
control stream. 


¢ Embedded control statements may be placed before or after the control sections 
in an object module, but may not be placed within a control section. 


® Embedded control statements that affect load module structure (LINKOP, 


LOADM, OVERLAY, REGION, and ENTER) cannot be embedded in an 
automatically included object module. 
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6.4. Embedded Control Statements 


Linkage editor contro] statements may be embedded in object modules either 
immediately after the object module header record or immediately after the object 
module transfer record. They may also be placed before or after the control sections in 
an object module, but may not be placed within a control section. Embedded control 
statements must be inserted in object modules prior to their being link-edited. The 
system librarian may be used to perform this function. 


Embedded statements are processed as are other control statements, except when a 
statement that affects the structure of a load module (OVERLAY, REGION, LINKOP, 
LOADM, and ENTER) is detected in an automatically included module. Because 
automatically included modules always are included in the root phase of a load 
module, these statements are not permitted to be embedded in automatically included 
modules and are flagged as errors in the link-edit map. If one or more object modules 
contain embedded INCLUDE control statements for a module (including itself) which 
is already being included, then an inclusion loop may result for the link-edit in 
question. 


All the control statements embedded in an object module are processed by the linkage 
editor, even if the object module is being accessed for a partial inclusion of its object 
code. 


Whenever the control statements LINKOP and LOADM are encountered as embedded 
control items, they immediately signal the end of the current link-edit but are never 
subsequently processed. Therefore, these control items must not be embedded in 
object modules with the implied intention of triggering multiple link-edit operations 
or (via LINKOP) of supplying additional parameters to the current link-edit. 


6.5. Basic Control Statement Processing 


The linkage editor cycles through two control modes for each load module it generates. 
The exact processing done in each mode is determined by the control statements 
processed in each mode. For this discussion, the control statements that affect the 
operation of the linkage editor are divided into two groups. The first group comprises 
all the control statements that direct the basic operation of the linkage editor and 
includes: 


e All job control statements directed to the linkage editor - start-of-data (/$), 
parameter specification (// PARAM), and end-of-data (/*) 


¢ All LINKOP statements 
¢ The LOADM statement 


These statements are processed in the first control mode. 
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The second group of control statements consists of those which basically affect the 
structure and content of the load module, rather than the operation of the linkage 
editor. All remaining linkage editor control statements comprise this group, and are 
processed in the second control mode. 


All the group 1 statements input to the linkage editor for the purpose of constructing 
any given load module may come from the primary control stream, plus any number of 
user source libraries. (See 6.6.1 for a description of the // PARAM and LINKOP CLIB 
keyword.) All group 2 statements, however, must come from a single source. The first 
group 2 statement detected initiates mode 2 processing, and mode 2 processing 
continues until INCLUDE processing is terminated for the load module. A given load 
module may thus pick up options and/or its load module name from multiple sources, 
but its structure must be defined in a single input source (primary control stream 
input or user source library). 


User source libraries for linkage editor control statements are specified by the CLIB 
keyword of the // PARAM or LINKOP control statements. The processing performed 
during construction of a load module depends, in some respects, on the source that 
contains the CLIB specification. In most cases, the statement containing the CLIB 
specification is the last statement processed for the current load module from the 
source that contains the CLIB specification. The only exception to this is if the source 
specified by the CLIB specification contains only group 1 control statements. If the 
linkage editor control statements are being input from the primary control stream 
when the CLIB specification is processed, the current location in the control stream is 
saved and is returned to when the control statements in the specified source are 
exhausted. In contrast, if a CLIB specification is processed while in a source library, 
the source library is disconnected and can never be returned to. Thus, it can be seen 
that multiple CLIB specifications can be meaningfully specified only in the primary 
control stream because only the first CLIB specification in a source module will ever 
be processed. 





A single link-edit job step that produces multiple load modules proceeds as follows: 


1. Enter mode 1 and process group 1 control statements for the first load module to 
be produced. 


2. Enter mode 2 and process all group 2 control statements to produce the first load 
module. 


3. Reenter mode 1 and process group 1 control statements for the second load 
module. 


4. Reenter mode 2 and process group 2 control statements to produce the second 
load module. 


5. Repeat steps 3 and 4 until all load modules are produced. 
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6.6. Control Statement Descriptions 


The following detailed descriptions of the basic linkage editor control statements are 
presented in their logical order of appearance in a linkage editor control stream. Each 
description includes the function of the control statement, illustrates its coding 
format, describes its parameters, and, when necessary, provides illustrated examples 
of how it may appear in a control stream. 


6.6.1. Specify Linkage Editor Options (// PARAM or LINKOP) 


Function 
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Specifies the linkage editor options that are to be in effect during construction of 
a load module. The options are declared as keywords in the operand field of 
either a // PARAM or LINKOP control statement. Both control statements 
perform the same function; however, the // PARAM statement cannot appear 
within a linkage editor control stream and the LINKOP statement cannot appear 
outside the linkage editor control stream. Thus, the initial linkage editor options 
may be specified either by a // PARAM or LINKOP control statement, but only 
the LINKOP statement can be used to change them within a job step. Each time 
a LINKOP control statement is processed by the linkage editor, it initiates the 
construction of a new load module. 


All option specifications take effect as soon as they are detected, and remain in 
effect until changed by a succeeding LINKOP control statement or until the job is 
terminated. This applies to system-supplied (default) parameter specifications as 
well as user-supplied specifications. Once a default specification is overriden by 
the user, the user-supplied specification remains in effect for the remainder of the 
job step unless the default specification is explicitly respecified by the user. When 
conflicting specifications are detected, the linkage editor assumes that the last 
statement is correct and functions accordingly. 


If no // PARAM or LINKOP control statements are present in a control stream, 
the linkage editor functions under the direction of the default parameter 
specifications, as follows: 

1. Performs automatic inclusion of required object modules, as necessary, and 
assumes that the standard system object library file ($Y$OBJ) is the only file 
that might contain the required modules. 

2. Processes V-CON references, as required. 


3. Stores the output load modules in the system job run library file ($Y$RUN). 


4. Uses only the control statements contained in the primary control stream to 
produce load modules. 
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5. Generates phase header records that contain blank comment fields and do 
not require the system loader to clear main storage before the phase is 
loaded. 


6. Processes all the control statements contained in the control stream, even if 
processing errors that would render a load module useless are detected. 


7. Provides for the promotion of common storage areas. 


8. Generates a link-edit for each load module generated that lists all the 
information normally desired in the link-edit map. 


9. Produces nonreentrant load modules. 


10. Recognizes reentrant object modules and creates the shared records needed 
to link their load module counterparts with the load module being created. 


11. Creates internal symbol dictionary (ISD) records in the load module. At " 


execution time, these records enable JOBDUMP to print a formatted dump 
of the load module area. 


LABEL | AOPERATIONA OPERAND 





{//] PARAM (ALIB=filename] 
LINKOP [ ,CLIB=modulename/ filename] 
,CMT= ae al | 
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a) 
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Notes: 


1. System-supplied parameters are in effect only until changed by the user. Once 
changed within a job step, they must be reset to their default state by the user 
before the default option is effected again. 


2. Keywords may be specified in any order, but they must be separated by 
commas with no spaces between the keywords unless they identify a delimited 
character string. 


3. Private file names that are declared are always logical and must be 
accompanied by the appropriate job control DVC/LFD statements. 


Label 


4/ 
Must be specified if PARAM operation is used. 


Keyword Parameter ALIB 


ALIB=filename 
Specifies the file to be searched during automatic inclusion processing. This 
keyword essentially provides the capability of naming an additional library 
for use during automatic inclusion processing. When specified, the ALIB 
} library always is searched first in an attempt to locate a required object 
module, and, if necessary, the file identified by the RLIB keyword is 
searched. 


If omitted, only the RLIB-specified file is searched during the automatic inclusion 
process. 


Keyword Parameter CLIB 


CLIB=modul ename/ filename 
Specifies the name of a source module, and the file in which it resides, that 
contains the linkage editor control statements to be processed for this link- 
edit job. When this parameter is detected in the primary control stream 
input, the linkage editor branches to the source module identified in this 
parameter, processes the control statements contained in the source module, 
then returns to the primary control stream to complete the processing of the 
remaining control statements, as applicable. When this parameter is 
detected in a source module control stream input, the linkage editor 
branches to the new source module identified in this parameter, processes 
the control statements contained in the new source module, and returns to 
the primary control stream. The linkage editor never returns to a source 
module control stream after processing the first CLIB keyword specification 
it detects in that control stream source. 


If omitted, the current control stream source (primary input or source module 
& input) continues to be accessed for control statements. 
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Keyword Parameter CMT 


CMT='character-string' 
Specifies a character string of up to 30 characters that is to be inserted in the 
comment field of each phase header record produced for the generated load 
modules. The character string must be enclosed in apostrophes and may 
contain blanks, commas, and other special symbols. 


CMT="A! 
Specifies that the phase header comment fields are to be blank. 


If omitted, the phase header comment fields are left blank unless a previous CMT 
keyword specification specified otherwise. 


Keyword Parameter OUT 


OUT=filename 
Specifies a library filename in which the output load module is to be stored. 
If a load module with the same name already exists in the output file 
specified by this keyword, it is replaced by the new load module. This 
filename corresponds to the LFD name assigned to the file. 


OUT=(N) 
Indicates that the output load modules produced by the linkage editor are 
not to be stored in any library file; however, the link-edit map will still be 
produced if it is not inhibited by the specification of the NOLIST keyword 


parameter. 





OUT=$YSRUN 
Specifies that the output load modules produced by the linkage editor are to 
be stored in the standard system job run library file ($Y$RUN). 


If omitted, the load modules produced are output to the system job run library file 
($Y$RUN) unless a previous OUT keyword specified otherwise. 


Note: The file designated to store the output of the linkage editor is logically extended 
to accommodate the load modules produced by the linkage editor. 


Keyword Parameter RLIB 


RLIB=f i lename 
This parameter is used to identify the file to be searched by the linkage 
editor, under the following conditions: 


¢ During the automatic inclusion process, when no automatic INCLUDE 
library file (ALIB) has been specified (no previous ALIB keyword 
specification present) or when the specified ALIB does not contain the 
required module ; 
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¢ During the specific inclusion process, when no file name is specified on 
an INCLUDE statement and either of the following conditions exist: 


- The module is not found in the standard job run library file 
($Y$RUN). 


- The module is not found in the file last specified on a prior 
INCLUDE statement or no prior INCLUDE statements exist. 


RLIB=$Y$OBJ 
Identifies the standard system object library file ($Y$OBJ) as the file to 
search under the conditions just described. 


If omitted, the standard system object library file ($Y$OBJ) is searched under the 
preceding conditions, unless a previous RLIB keyword specified otherwise. 


Keyword Parameters CNL and NOCNL 


CNL 

Specifies that the link-edit job is to be canceled at the end of the link-edit 
operation for the current load module if any diagnostic processing has been 
triggered during the generation of the load module; otherwise, processing 
continues, regardless of the number or type of error diagnostics triggered, 
until the normal end-of-job function for the link-edit job step is detected. 


@ NOCNL 


Specifies that the link-edit job step is to be processed to completion, 
regardless of the number or type of diagnostic errors detected. 


If omitted, NOCNL is assumed unless the CNL keyword was previously specified. 
Keyword Parameters ZRO and NOZRO 


ZRO 
Specifies that the job region is to be cleared to binary zeros prior to loading 
the root phase of the load module. This option is effective only if this load 
module name is specified on the // EXEC job control statement. Specification 
of this keyword sets a flag in the root phase header record to indicate the 
clearing requirement to the system loader. 


NOZRO 
Specifies that main storage is not to be cleared to zeros before the root phase 
of the load module is loaded. 


If omitted, NOZRO is assumed unless the ZRO keyword was previously specified. 
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Keyword Parameters AUTO and NOAUTO 


AUTO 
Specifies that automatic inclusion processing is to be allowed for the load 
modules being constructed. 


NOAUTO 
Specifies that automatic inclusion processing is not to be allowed for the load 
modules being constructed. 


If omitted, AUTO is assumed unless the NOAUTO keyword was previously 
specified. 


Note: The NOAUTO specification does not affect the automatic inclusion of the 
overlay control routine if V-CON processing is not inhibited (NOV keyword 
not specified) and valid V-CON references exist in the object code being 
included in the load modules being produced. 


Keyword Parameters V and NOV 


v 
Specifies that V-CON references are permitted to appear in the object 
module elements to be included in the load modules and, therefore, that 
automatic loading of required phases is to be enabled. 

NOV 


Specifies that V-CON references are to be treated as A-CON references and, 
therefore, that automatic loading of phases is to be inhibited because it is not 
required. This specification is significant only when valid V-CON references 
are present in the object module elements being included. 


If omitted, V is assumed unless the NOV keyword was previously specified. 
Keyword Parameters PROM and NOPROM 
PROM - 
Specifies that common storage areas are to be promoted to the most 
reasonable phase within the load module being constructed. 
NOPROM 
Specifies that all common storage areas are to be placed in the root phase of 


the load module being constructed. 


If omitted, PROM is assumed unless the NOPROM keyword was previously 
specified. 
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Keyword Parameters LIST and NOLIST 
LIST 
Specifies that all list options for the link-edit map are to be in effect for the 
current link-edit job. 


NOLIST 
Specifies that no link-edit map is to be produced for the current link-edit job. 


If omitted, the standard link-edit map will be produced unless LIST or NOLIST 
was previously specified. 


Keyword Parameters CNTCD and NOCNTCD 


cNTCD 
Specifies that the process map portion of the link-edit map is to be produced. 


NOCNTCD 
Specifies that the process map is to be suppressed. 


If omitted, CNTCD is assumed unless NOCNTCD was previously specified. 
Keyword Parameters ERR and NOERR 
ERR 
Specifies that diagnostic messages and unresolved references are to be 


included in the link-edit map. 


NOERR 
Specifies that this information is to be suppressed. 


If omitted, ERR is assumed unless NOERR was previously specified. 
Keyword Parameters DICT and NODICT 

DICT 
Specifies that the definitions dictionary and phase structure diagram 
portions of the link-edit map are to be produced. 

NODICT 
Specifies that the definitions dictionary and phase structure diagram 
portions of the link-edit map are to be suppressed. 


If omitted, DICT is assumed unless NODICT was previously specified. 
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Keyword Parameters DEF and NODEF 


DEF 
Specifies that object module headers (including dates and times) and 
CSECT, COM, and ENTRY itéms are to be listed in the allocation map 
portion of the link-edit map along with their respective object module origin 
and ESID, length, linked base address, and high limit after linking. 


NODEF 
Specifies that listing of ESDs is to be suppressed. 


If omitted, DEF is assumed unless NODEF was previously specified. 
Keyword Parameters PHS and NOPHS 


PHS 
Specifies that phase data (phase name, alias-phasename, origin, length, 
transfer address, etc.) is to be listed in the allocation map portion of the link- 
edit map. : 


NOPHS 
Specifies that the phase data is to be suppressed. 


If omitted, PHS is assumed unless NOPHS was previously specified. 
Keyword Parameters DEL and NODEL 


DEL 
Specifies that all definitions, including those automatically deleted due to 
redundant inclusions on identical paths or items not included because of 
partial INCLUDE specifications, are to be listed in the allocation map so 
long as definitions are being listed (NODEF is not specified.). 


NODEL 
Specifies that automatically deleted or excluded definitions are not to be 
listed. 


If omitted, NODEL is assumed unless DEL was previously specified in the 
control stream. 


Keyword Parameters RCNTCD and NORCNTCD 


RCNTCD 
Specifies that control statements are to be included in the allocation map 
portion of the link-edit map. This allows the user to easily locate a particular 
control statement and see its effect on the load module. Only action-type 
control statements are included in the allocation map; // PARAM and 
LINKOP statements are never listed here. ; 
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NORCNTCD 
Specifies that control statements are not to be listed in the allocation map. 


If omitted, NORCNTCD is assumed unless RCNTCD was previously specified. 
Keyword Parameters REF and NOREF 


REF 
Specifies that the allocation map portion of the link-edit map is to list all 
references (EXTRNs) and transfer records processed, the object module 
assigned address and ESID, and the resolved value, if appropriate. 


NOREF 
Specifies that this information is to be suppressed. 


If omitted, NOREF is assumed unless REF was previously specified. 
Keyword Parameters SHARE and NOSHARE 


SHARE 
Specifies that object modules marked reentrant are to be recognized during 
the inclusion process (specific and automatic). The text from such modules is 
not to be included. Instead, shared records are to be created for references 
made to reentrant code. The load module produced is nonreentrant, but may 
contain references to reentrant code. This keyword is ignored if a reentrant 
load module is being generated (the RNT keyword is specified) or the job 
control GO option is in effect. 


NOSHARE 
Specifies that all object modules are to be treated as nonreentrant and no 
shared records are to be generated. A nonreentrant load module is produced 
that contains no references to shared code. 


If omitted, SHARE is assumed unless the NOSHARE keyword was previously 
specified. 


Keyword Parameters RNT and NORNT 


RNT 
Specifies that a reentrant load module is to be produced and SENTRY 
records are to be generated. Normally, only one object module would be 
included in the link-edit, in which case, the load module name must be the 
same as the object module name. Parameter NOAUTO should be specified 
when using the RNT parameter. 


NORNT 
Specifies that a nonreentrant load module is to be produced although 
references may be made to reentrant code. 


If omitted, NORNT is assumed unless RNT keyword was previously specified. 
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Keyword Parameters ISD and NOISD 


ISD 


Specifies that Type 3 and Type 4 ISD records from the included object 
module are relocated and passed to the load module. It also specifies that 
Type 1 and Type 2 ISD records are generated based on the undeleted 
CSECTs and COMMONs detected during the link-edit. If execution of the 
load module terminates, these records are used by JOBDUMP (if specified) 
to print a formatted dump; segmenting it by CSECTs and printing user 
program symbols. 


NOISD 


Specifies that ISD record generation is to be suppressed. 


If omitted, ISD is assumed unless NOISD keyword was previously specified. 


6.6.2. Begin Load Module (LOADM) 


614 


Function 


This control statement is used to initiate construction of a load module. Also, it 

specifies a program name for the load module. The LOADM control statement is 

normally the first control statement in a control stream, but it may follow a . 
LINKOP or comment statement, or a complete set of previous control statements & 
when used in a control stream that is generating more than one load module. 


If the LOADM control statement is omitted from an otherwise valid linkage 
editor control stream and no LOADM control statement is embedded in an 
included object module, by default, the load module produced by the linkage 
editor is assigned the name LNKLOD. 


Format 


LABEL |AOPERATIONA OPERAND 





Positional Parameter 1 


name 


One to six (eight, if it is the link-edit of a reentrant module) alphanumeric 
characters, the first of which must be alphabetic, that specifies the name to 
be assigned to the load module. If the specified name is less than six (eight, if 
it is the link-edit of a reentrant module) characters long, it is padded on the 
right with EBCDIC zeros. If the specified name is more than six (eight, if it 
is the link-edit of a reentrant module) characters long, it is truncated to the 
maximum allowable limit. , 
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If omitted, the default name LNKLOD is assigned to the load module. 


6.6.3. Include Object Code (INCLUDE) 


Function 


Requests that a specific object module or selected control sections of a specific 
object module be included in the current phase of the load module being 
constructed. The INCLUDE statement may follow any linkage editor statement 
except the ENTER statement. Also, it may be embedded in an object module. 
Nesting of embedded INCLUDE statements may continue indefinitely. Nested 
INCLUDE statements are identical in format and capability to those not nested 
and may thus specify full or partial inclusion, as well as alternate files. The same 
applies during the automatic inclusion process, although the initial module 
located and used to satisfy a specific reference always is included in full. 


If no INCLUDE statements are present in an otherwise valid linkage editor 
control stream, all the object modules currently residing in the system job run 
library ($Y$RUN) are included in the load module phase being constructed. 


Format 


LABEL |AOPERATIONA OPERAND 


INCLUDE (modulename][s1,...,S9)1[, filename] 


Positional Parameter 1 


modul ename 
Is a one- to eight-character alphanumeric character string that identifies the 
object module to be included. 


If omitted, it is assumed that the INCLUDE statement is nested and that the 
object module being referenced immediately follows the previously referenced 
object module in the library being accessed. Otherwise, an error message is 
output on the link-edit map. 


Subparameters 
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S1,...,89 
Is a list of from one to nine control section labels (one to eight characters 
long) that identify the control sections to be included in the load module 
phase being constructed. The control sections referenced in this parameter 
must be contained in the object module referenced by the INCLUDE 
statement; otherwise, an error diagnostic is output on the link-edit map. The 
order in which the control sections appear in the object module is the order 
in which they will appear in the load module, regardless of the order in 
which they are listed in this parameter. 
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6.6.4. Begin Overlay Phase (OVERLAY) 


Function 


6-16 


When a subparameter list is specified, no unnamed CSECT in the module 
being scanned is ever included in the load module, but all requests for 
common storage are honored, as are all embedded control statements. 


If omitted, the entire object module is included in the load module except for 
those control sections that may be automatically deleted by the linkage editor. 


Positional Parameter 2 


filename 
Is a one- to eight-character alphanumeric character string that identifies the 
symbolic name of the file in which the referenced object module is stored. 
This name must be specified exactly as it is specified in the job control logical 
file definition (LFD) that identified the file; otherwise, an error message is 
output on the link-edit map. When this parameter is specified, it is the only 
file searched for the specified object module. 


If omitted, the object module is assumed to be in the system job run library — 
($Y$RUN) or, if not there, in the last library specified in an INCLUDE statement 
or, if not there and a file name was specified in a previous RLIB keyword in that 
file; otherwise, if no RLIB library was specified, the object module is assumed to 
be in the default RLIB library, the system object library file ($Y$OBJ). 





Identifies the beginning of an overlay phase (a phase other than the initial phase) 
and defines the relative position of the phase within the load module structure. 
The object modules included thereafter constitute a single, separate phase until 
the next OVERLAY, REGION, LOADM, LINKOP, or end-of-data (/*) control 
statement is detected. 


This statement must not be used in the link-edit of a reentrant module. 


Format 


LABEL jAOPERATIONA OPERAND 


OVERLAY symbol [, al ias-phasename] 


Positional Parameter 1 


symbol 
Is the name of a logical or relative node point that defines the starting 
address of the phase. It may consist of one to eight alphanumeric characters. 
If the symbol is relative (a CSECT, ENTRY, or EQU name), it must be on the 
path of the phase. However, the relative symbol must not be a shared 


definition. @ 
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The symbol specified may cause the phase to begin at an origin newly 
established by this node name or may set that origin to an address defined 
by a previous OVERLAY statement, the LOADM statement, or a relative 
definition (provided it is on the current path). 


The starting address of a phase is not necessarily the entry point to that 
phase; therefore, use of the symbol in the operand field of an OVERLAY 
statement does not automatically define the symbol as an entry point. The 
same symbol, however, may be used to define both the entry point to this 
phase and the logical (or relative) origin of the phase (if in the current path). 
If the symbol is on an exclusive path, a logical node is established. 


Positional Parameter 2 


al ias-phasename 
Is a one- to six-character user-supplied phase name that can be used in 
placed of the linkage-editor-supplied phase name, to address the phase being 
created by the OVERLAY statement. If an alias phase name longer than six 
characters is supplied, it is truncated to six. Alias-phasenames are always 
padded with two trailing blanks. 


6.6.5. Begin New Region (REGION) 


Function 


Initiates construction of the first phase in a new region, starting at the end of the 
longest path currently constructed for the load module. Once a region has been 
started, no prior region structure may be continued. Thus, all parts of a given 
region should be fully specified and structured before beginning a new region. 
The only phase common to all regions in a load module is the root phase. 


OVERLAY control statements may be interspersed among REGION control 
statements to structure the phases within each region. The first of any region, 
including the initial phase, may be overlaid by referencing the region node (or 
LOADM node) or a symbol with that address, using an OVERLAY control 
statement. Inasmuch as the REGION statement effectively replaces an 
OVERLAY statement, INCLUDE and other control statements used for the 
construction of a phase follow immediately. Up to 10 regions may be declared for 
a single load module. 


This statement must not be used in the link-edit of a reentrant module. 


Format 


LABEL | AOPERATIONA OPERAND 


REGION symbol {, al ias-phasename] 
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Positional Parameters 1 and 2 


Refer to parameter descriptions for the OVERLAY control statement. Note that 
inasmuch as the implied origin of a new region always is at the end of the longest 
path of the current region, a symbol in a REGION statement may specify only a 
logical node name and not a relative definition name as in the case in an 
OVERLAY statement. 


6.6.6. Define Phase Execution Entrance (ENTER) 
Function 


Defines the program entry point of the load module phase being constructed. This 
is the address to which program control is optionally transferred when the phase 
is loaded by a supervisor FETCH macroinstruction. The ENTER statement, if 
present, is normally the last control statement issued for a given phase. It may, 
however, be followed by a MOD, EQU, RES, or comment statement in addition to 
an OVERLAY statement for the next phase, a REGION statement for a new 
region, a LOADM or LINKOP statement for a new load module, or an end-of-data 
(/*) statement, which terminates execution of the linkage editor. 


If an INCLUDE statement immediately follows an ENTER statement, a 
diagnostic warning indicating the sequence error is listed on the link-edit map, 
but the INCLUDE statement will, nonetheless, be processed for the current 
phase. 





If no ENTER statement is provided for a phase, the phase entry point, or transfer 
address as it is commonly referred to, is obtained from the first specifically 
included object module in the phase that has a valid transfer address. If no 
specifically included object module contains a valid transfer address, the entry 
point address used by the linkage editor is the relocated address assigned to the 
first CSECT specifically included in the phase. Automatically included modules 
are not checked for valid transfer addresses. If no CSECTs have been included in 
the phase (zero length phase), then the transfer address is assigned to the node 
point of the phase. 


Format 
LABEL | AOPERATIONA OPERAND 
ENTER [expression] 
Positional Parameter 1 
expression 
Specifies the transfer address for the phase. This expression, which usually 


represents a relative phase address, may have one of the following forms: 


¢ Adecimal number from one to eight digits long. @ 
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¢ A hexadecimal number from one to six digits long, in the form 
X‘nnnnnn’. 


e Apreviously defined symbol (the name of a control section or an entry 
point in an object module that was previously included or defined by a 
previous EQU directive). For the link-edit of a nonreentrant module, 
this symbol must not be a shared definition. 


e Apreviously defined symbol plus or minus a decimal or hexadecimal 
number as previously described. 


If omitted, the ENTER statement has no effect and the default criteria previously 
described apply. 


6.6.7. Define Label (EQU) 
Function 
The EQU control statement is used to provide the linkage editor with the value of 


a label that might not otherwise be defined. The definition of a symbol by an EQU 
statement is subject to the same rules for automatic deletion as entry points. 


Format 


LABEL |AOPERATIONA OPERAND 


symbol | EQU expression 
Label 
symbol 
Is a one- to eight-character alphanumeric character string, which is the label 
to be defined. 


Positional Parameter 1 
expression 
Specifies the value to be assigned to the label. The expression may have one 
of the following forms: 
¢ Adecimal number from one to ten digits long. 
e Ahexadecimal number from one to eight digits long. 


e A previously defined label (the name of a control section or an entry 


point in an object module that was previously included or defined by a 
previous EQU statement). 
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¢ A previously defined label plus or minus a decimal or hexadecimal 
number, as previously described. For the link-edit of a nonreentrant 
module, this label must not be a shared definition. 


e An asterisk (*) to indicate a reference to the current value of the 
location counter. 





DDSAC EQU 32 


1 
2. |DDECT1 QU x'20! 
3. |DPSCHK1 EQU  DDECT1 
4. |DPSCHK2 EQU DDECT1 6X'20! 
5. |DPSCHK3 EQU * 

1. Equates the label DDSAC to the decimal value 32. 

2. Equates the label DDECT!1 to the hexadecimal value 20. 

3. Equates the label DPSCHK1 to the value of the label DDECT1. 


4. Equates the label DPSCHK2 to the value of the label DDECT1 plus the 
hexadecimal value 20. 





5. Equates the label DPSCHKS3 to the current value of the location counter. 
Notes: 


1. If the operand of the EQU statement is symbolic (a previously defined symbol 
is involved) and the label supplies a multiple definition, then no such earlier 
definitions may occur between the definition of the operand symbol and the 
EQU statement itself. If a symbolic operand is multiply defined, the label of 
the EQU statement is equated to the last such definition. 


2. KE$ALP and KE$RES, which are the addressable entry points to the reserve 
storage area, cannot be used as operands of the EQU control statement. 


6.6.8. Modify Location Counter (MOD) 


Function 


The MOD control statement instructs the linkage editor to adjust its location 
counter to coincide with a specific power of 2 and a specific remainder. Initially, 
the location counter is set to zero by the LOADM control statement, and then 
incremented by the length of each control section included in a phase. Also, it is 
set to the value associated with a node point when an OVERLAY or REGION 
control statement is detected in the control stream. 


6-20 UP-8841 Rev. 4 


Control Statements 


ee 


@ Format 


LABEL |AOPERATIONA OPERAND 





power [, { remainder 
f \ (8) 
Positional Parameter 1 


power 
Is a decimal or hexadecimal (X‘n’) number that specifies the power of 2 
relative to which the location counter is to be adjusted. The only acceptable 
powers of 2 that may be specified are 8, 16,32, 64, 128, 256, 512, 1024, 2048, 
4096, 8192, 16384, and 32,768. 


Positional Parameter 2 


remainder 
Is a decimal or hexadecimal (X‘n’) number that is a multiple of 4, which 
specifies the desired remainder of the new value of the location counter 
relative to the specified power of 2. If the decimal number specified for this 
parameter is not a multiple of 4, it is rounded to the next higher multiple of 
4, then truncated to a value less than the specified power of 2. 


@ If omitted, the remainder is assumed to be zero. 
Example 
1 10 16 
MOD 32,8 


This control statement instructs the linkage editor to adjust its location counter, 
if necessary, to a value that is 8 more than a multiple of 32. 


e If the current value of the location counter is 16,384, which is an exact 
multiple of 32 (32 x 512 = 16,384), the location counter would be incremented 
by 8 to a value of 16,392. 


e If the current value of the location counter were 16,392, no adjustment would 
be required. 


e Ifthe current value were 16,400, which is 16 greater than a multiple of 32 
(32 x 512 + 16 = 16,400), the new value would be adjusted to 16,424 
(32 x 513 + 8 = 16,424). 
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6.6.9. Reserve Storage (RES) 
Function 


Instructs the linkage editor to reserve additional load module storage space 
following the end of the longest path in the highest region of the load module. The 
additional storage requested by the RES statement adds to the total length of the 
module, and is recorded in each phase header record, but is not included in the 
size requirements for any particular phase. One or more of these statements, 
therefore, may be placed anywhere within the control stream for a load module. 
The sum of all RES values processed during the construction of a load module is 
used to extend the longest path of the load module. 


The linkage editor automatically assigns two addressable entry points to the 
reserve storage area. These entry points may be addressed by the user to access 
the reserve storage area by declaring them as EXTRNS in your program. The two 
addressable entry points assigned are: 


e KE$ALP - which is the effective address of the end of the longest path in the 
load module, or the starting address of the reserve storage area. 


¢ KES$RES - which is the effective address of the end of the longest path plus 
the sum of all the reserve storage area size specifications (RES statements). 


These two entry points cannot be used in the operand field of the EQU control 
statement. 





Format 
LABEL |AOPERATIONA | OPERAND 
RES value 
Positional Parameter 1 
value 
ope the number of bytes of storage to be reserved in one of the following 


© Decimal number from one to ten digits long 


¢ Hexadecimal number one to eight digits long, in the form X‘nnnnnnnn’ 
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Link-Edit Map 


7.1. Introduction 


Unless otherwise specified in a // PARAM or LINKOP control statement, the linkage 
editor produces a link-edit map for each link-edit job it performs. Basically, the map 
details the load module produced by the linkage editor, and is produced in six parts: 
1. Process map 

2. Unresolved EXTRN reference list 

3. Definitions dictionary _ 

4, Phase structure diagram for multiphase load modules 

5. Allocation map 


6. | Error legend and count list 


However, via // PARAM or LINKOP parameter specifications, all or part of the link- 
edit map may be suppressed. A detailed description of each map part follows. 


7.2. Process Map 


The initial part of the link-edit map is a listing of the linkage editor control stream 
used to produce the subject load module (see Figure 7-1). Both the control statement 
specifications listed by the user and those inserted by the linkage editor in the control 
stream from referenced source and object modules are listed. Special process map 
messages also may appear in the process map. These messages, which are always 
enclosed in asterisks, are used to explain the presence of some of the control 
statement data included in the process map. The special messages are listed and 
described in Table 7-1. 
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Figure 7-1. Typical Link-Edit Process Map Listing 


Table 7-1. Special Process Map Messages 





Message Meaning 

*AUTOINCLUDED* Item was, of necessity, automatically included. 

*EMBEDDED* Control statement, as processed, exists within an included 
object module. 

*GENERATED* Anecessary control statement was generated by the linkage 
editor. 

*SORS FILE* Control statement processed resides within a source module of 
linkage editor directives. 

*RUN LIBE MODULE * Module was included by default from the job run library (/* item 


is not printed on process map). 


Diagnostic warnings also may be interspersed among in-error control statements and 
the processing triggered by their presence. These messages always are delineated by 
five leading dashes (- - - - - ) and an error code. They are listed and described in the 
System Messages Reference Manual (UP-8076). 


The process map may be suppressed by the declaration of the NOCNTCD keyword 
specification in the // PARAM or LINKOP control statement. 
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7.3. Unresolved EXTRN Reference List 


If, after all INCLUDE processing terminates, references are made to one or more 
symbols for which no corresponding definitions exist, a list of the undefined symbols is 
output on the link-edit map and the UPSI byte is set to X‘20’. The symbols are not 
sorted into any sequence and are listed only for the convenience of the user (see 
Figure 7-2). After this list is generated and all CSECT, relocation, and phase sizes, 
and address assignments are computed, diagnostic messages may be interspersed 
among the list of undefined EXTRN references, as applicable. 





OUNRESOLVED JE FERENCSS © 
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40 3080¢ a0 3090¢ a0 3190C ao 3140C ausizoc 40 3130¢ a0 3180C aC 31 UE A03310E a0 3120E 
£o 32306 AO SINCE a01010€ aGioece AC 1O30£ 40 1G80E aoZ0I0€ a02020E 402030€ A02080E 
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40 3060€ AQ 3670£ AO 3030€ AG 3090 £ 
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Figure 7-2. Typical Unresolved EXTRN Reference List 


7.4. Definitions Dictionary 


The definitions dictionary part of the link-edit map lists and describes all the symbols 
referenced in the link-edit job. These symbols are listed alphabetically, in three 
horizontal columns (see Figure 7-3). Each symbol definition includes 

¢ Type identification 

¢ Phase assignment identification for nonshared items 

¢ Linkage-editor-assigned address when applicable 


¢ Optional information character 


The type identifications that may be specified for a symbol and their meanings are 
listed in Table 7-2. 


The phase assignment identification identifies the load module in which the symbol 
appears. The phase identifications that may appear in this field are listed and 
described in Table 7-3. 
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Figure 7-3. Typical Link-Edit Definitions Dictionary List 





Table 7-2. Definitions Dictionary Type Identifications 


Type Meaning 
COM" Identifies a common section name. 
ENTRY Identifies an absolute or relative entry point definition. 
CSECT * Identifies a control section name. 
EQU Identifies a link-time-defined symbol for an entry point. 
EQU* identifies a link-time reference to the location counter for an 
entry point. 
EXTRN Identifies a symbol referenced but never defined (also listed in the 


unresolved EXTRN references list). 


' if a COM or CSECT symbol name is blank, the item listed represents a blank common 
or unnamed control section, respectively. 
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Table 7-3. Definitions Dictionary Phase Field 


Phase Meaning 

1-99 Load module phase number 

ROOT Root phase 

ABS Absolute ENTRY symbol (no phase assignment applicable) 


EXTRN symbol (no phase assignment applicable) 


SHR Shared definition 


The address field is expressed in hexadecimal and may be absolute or relocatable, 
depending on the definition type. Dashes appear in the address field of EXTRN 
symbols. Blanks appear in the address field of shared definitions since they do not 
have an address. 


The information characters that also may appear in a symbol definition are listed and 
described in Table 7-4. When included, these characters are listed between the 
PHASE and ADDRESS fields of a symbol definition. 


Table 7-4. Definitions Dictionary Information Characters 


Character Meaning 


G Used to identify a dictionary item referenced by text and included in the load module 
during a partial INCLUDE sequence, and defined in another CSECT of the same object 
module that was not to be included in the load module. Whenever such a symbol is 
detected, the linkage editor generates an EXTRN label for the symbol in hopes of 
satisfying the reference. No automatic INCLUDE processing ever is triggered for such 
references and, therefore, the symbol remains undefined unless specifically obtained by 
the user through an INCLUDE or EQU statement. 


M Used to identify a symbol that is multiply defined and, therefore, listed at least twice. 
V Used to indicate that a symbol is a valid type V definition and is a candidate for 
residence in the entry point table (KLSNTB) for V references. 


Printing of the definitions dictionary can be suppressed by a // PARAM or LINKOP 
control statement that specifies the keyword NODICT; however, suppression of the 
definitions dictionary also causes suppression of the phase structure map. 
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7.5. Phase Structure Diagram 


Ascaled pictorial drawing for multiphase load modules is provided next in the link- 
edit map (see Figure 7-4). This figure depicts the phase and overlay structure of the 
load module being generated. Each phase is shown with its linked load origin in 
association with other phases. Each phase is identified by a decimal phase number 
and its size is listed in hexadecimal. Vertical bars (1) represent established node 
origins; horizontal bars (dashes) represent the phase lengths. Each printer bar is 
intended to depict a specific number of bytes with regard to phase storage needs and is 
scaled to a predetermined factor that is specified in the heading of the listing. In 
Figure 7-4, each horizontal bar represents 0D hexadecimal (13 decimal) bytes. 


The phase structure diagram can be suppressed by a // PARAM or LINKOP control 
statement that specifies the keyword NODICT; however, suppression of the phase 
structure diagram also causes suppression of the definitions dictionary. In either 
event, no phase structure diagram is produced for single-phase load modules. 
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Figure 7-4. Typical Phase Structure Diagram 
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7.6. Allocation Map 


The allocation map provides a detailed description of the items processed during the 
link-edit operation. The following operation, depending on the // PARAM or LINKOP 
specified parameters, may include: 

¢ Name and size of the load module. 

e Linkage editor assigned name of each phase (and possible alias-phasename), and 
an indication of any common storage areas assigned to the phase (COMMON 
indicates residence in current phase). 

e Origin, length, and high address of each phase. 

e Transfer address assigned to each phase. 

¢ Name, type, and ESID of each definition or reference processed. 

¢ Linked origin, high address, length, and object module origin (if applicable) of 
each definition or reference processed; certain language processors omit the 
length field in the CSECT record but indicate it in the transfer record. When the 
linkage editor lists such a CSECT, the high address is omitted, the word 
DEFERRED appears under the LENGTH heading, and the code L appears under 
the FLAG reading. The actual CSECT length is printed when the transfer record 

& is listed. Blanks appear in the link origin high address and length field for shared 
definitions. 

¢ Set of flag codes for items representing special conditions. 

¢ Relist of interspersed control statements that triggered the results shown. 


¢ Indication of the accessed object modules and whether they were automatically 
included or not. 


© Object module transfer records processed. If the deferred length is present, it is 
printed under LENGTH and the code L appears under FLAG. 


A typical allocation map is illustrated in Figure 7-5. 
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acsose csect os 300033 78 30003390 Oo 2000 18 o00000z8 
: a0 503E ENTRY 2s 30963386 o0n000 36 
c2c 00378 
$x190008 NIDE - 800E35 30003390 20062308 30002018 
~ 00/01/88 06.56 - aos ws 
ao SoNc csict 36 20003390 30963348 300090 28 oon0008e 
aC 50st IMTRY 36 320003342 00000052 
03000393 
$0120 065 HIDE - #00895 300033a8 200093C8 90000020 
- 00/01/88 06.56 - acs obu ‘ 
40 503¢ escct o7 30603348 doaco3ce 20003020 oooo00se 
a0 SOSE ENTRY | ar 3000338E OOGOD06E 
c20003A6 
$4190 008 MODE - 400£36 220033¢8 30962358 30309020 
- 00/01/88 06.56 - aos wou 
£0 509C csect 38 3000I3c8 300033£8 30903020 000000 78 
a0 SOSE ENTRY os 30 9033€2 00000092 
G30 003C8 
$8130007 wODE - 400€37 300033€8 30903910 30000028 
= 00/01/88 06.56 - acs o6u 
aoso7c Csect a9 300033€8 30260410 30003026 o0p00098 
ac SO7E ENTRY aF 300038 26 ooo000 86 
€309u3€8 
$%120008 WIDE - WODEI8 30 003910 203034 38 20009028 
~ 00/01/88 96.56 - acs bidhed 
acscac cscc? oA 20003810 363039 38 30300026 ooocaoce 
40 503€ ENTRY oa 300034 32 a00000E2 
G36u0819 
$4190009 MODE - WO0EI9 300034 38 800604568 303030 30 
- 00/91/88 06.56 - aos aad 
acsoac esect oe 200034 38 303023968 200020 30 900000€8 
ad som 2WTRY 0B 30 9634 SE 000001 0& 
: 63006838 
$4190017 WIDE - 40 O£10 30003468 303009 98 393030 30 
~ 08/01/88 06.56 - aos Bu 
a0352I9C csecr ac 30002468 3033498 203030 30 000001 88 
a0 52I€ Entry oc 300034 92 00000142 
C2000868 
PHASE MAME TRANS AIDR FLAG Lager TYPE €s12 LNK ORG HIA0OR LENGTH OBJ ORG 
$a130011 WIDE -  NODELI 20702598 20003900 200000 38 
- 00/01/88 06.56 - acs Bd 
aGStic esict 20 30003498 30009800 30.0000 38 oo0001se 
AOSIIE zmTRY oo 200024 C6 000001 76 
030 00898 
$m220012 WIDE - MOOELZ 200034900 320003508 c02000 38 
- 00/01/88 06.56 - acs Pe) 
aG.$22C CSECT ae 30003490 90009598 300000 38 000001 90 
8O SIZE entey ae 20003822 0c000162 
0200800 a: 
$8130013 waDe - #00815 300035 38 20009548 90000090 
~ 00/01/88 06.56 - acs wu 
0513 csict oF 30003508 2000u588 90900040 ococores 
aOS1se Entry oF 300035 3E 00001 €€ 
cicocsos 
$a1290018 NODE - NODEIS 22909358 20000398 00000080 
- 00/01/88 06.56 - 05 wed 
a0S3ac esect 10 30903358 30063398 30000080 900001F8 
€O SEE INTRY 10 90003392 00000232 
03000388 
$a190035 NODE - NOODEIS 300023 98 200093 98 30000000 
cret-KOF2- 3H 109015 ZERO LENGIH PHAS: 
62000398 
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Figure 7-5. Typical Allocation Map 





78 , UP-8841 Rev. 4 





Link-Edit Map 





7.7. Error Legend, Error Count List, and UPSI Setting 


The final part of the link-edit map concerns the termination of the link-edit job itself. 
An error code legend is printed, indicating the meanings of flags that may have been 
detected during the link-edit job. The error legend is followed by a printout showing a 
count of the number of errors appearing in the link-edit map and an UPSI byte setting 
at the end of the map. The flag code legend is summarized in Table 7-5. 


If the link-edit job has been successful, a completion message and the date/time will so 
indicate. A typical error legend and count list is illustrated in Figure 7-6. 


Table 7-5. Error Legend and Count List Flag Code Descriptions 


Flag Code 


B 


UP-8841 Rev. 4 


Description 


The control section is considered a block data CSECT and is to be used to load 
a common storage area. 


The item has been automatically deleted because another relative definition for 
the same symbol is in the same path or one absolute definition already exists. 
If a transfer record is involved, the item has not been accepted for processing 
because no valid address is in the record. 


A direct A-type reference has been made, which is exclusive and whose definition 
may not be resident with the reference. 


An EXTRN has been generated because of the partial inclusion of a control section 
whose text references a control section that is not included. 


A V-type reference has been made to a definition that is inclusive and, therefore, 
has been converted to a direct type A reference. 


A deferred CSECT or COMMON length is in effect, and the actual length is listed 
with the object module transfer record. 


The item is validly multiply defined in this link-edit. 


The item has not been included because of a partial INCLUDE, which purposely 
omitted it. 

The item is a COM storage area and has been promoted to another phase based 
on the phases in which it was declared, the references which point to it, and 

the block data CSECTS which load it. 


A shared record has been produced for this item. 


continued 
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Table 7-5. Error Legend and Count List Flag Code Descriptions (cont.) 





Flag Code Description 

S$ This is a shared item. 

U The item was unresolved and remains undefined in the load module. 

V The item is a V-CON item and will be loaded automatically when 

referenced by a type V constant. 
Fras CODES - 

@ - M8 Dets CSFCT M - euto-o8nF feo € - ERCRUSTVE O° REF © - GEMERATEO ExTan 3 - INCLUSIVE cee REF 
t - GFeseata ceuGtn oe - muetsory OFF iO w - BOT TeciuorD ~ > - PROMOTED CONRON @ - SHARED BEC PRODUCED 
& - Suasen Tiger uv VEOET INE OD OFF vw - eConm Bten 


OSNT OteFe CODES AF PRESENT PROCESS FRRORSS 


Lime fO1T OF cPRetOR® «Commie TF O 
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€e00e% PmreusteA—O- GOOG uPsE- B°00° 
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Figure 7-6. Typical Error Legend and Count List 
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Section 8 
Program Examples 


A representative set of link-edit jobs is illustrated in this section. Figure 8-1 
illustrates a typical job control stream that could be used to execute the linkage editor, 
while Figures 8-2 through 8-6 illustrate the link-edit maps produced for each job. 
Figure 8-2 illustrates a rather simple single-phase load module. Figures 8-3 through 
8-5 illustrate some typical multiphase load modules, and Figure 8-6 illustrates a 
rather sophisticated multiphase load module. 





// JOB LINKSTA 

// DVC 20 // LFD PRNTR 

// WORK1 

// EXEC LNKEDT 

/$ 

** LINKAGE EDITOR CONTROL STATEMENTS GO HERE ** 
/* 

/& 

// FIN 


Figure 8-1. Typical Linkage Editor Job Control Stream 
Notes: 


1. When storage is available, the job card should specify a maximum storage size of 
X 8000’ for optimum performance. If you omit the maximum main storage 
parameter, job control allocates the minimum and maximum main storage 
requirements to execute the linkage editor. The speed of the linkage editor is 
directly related to the amount of main storage allocated to the job. 


2. The printer must always be allocated regardless of the fact that the list options 
selected may cause only minimal printing. 


3. Ifthe keyword parameter EXTSP is coded on WORK] jproc, a minimum value of 5 
must be specified. 
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Program Examples 


&2 


In addition to using the | | EXEC LNKEDT statement to call the linkage editor, a 
job procedure call statement (jproc call) is also available. The jproc call is an 
easier method for executing the linkage editor. For example, if all the defaults 
associated with either the //| PARAM or LINKOP statement were utilized, and the 
only other linkage editor control statement required was the LOADM statement, 
the following jproc call can be used: 
// LINK 

By using this one statement, the following is automatically generated: 

¢ = Printer assignment 

¢ Work file 

e EXEC LNKEDT statement 

e {| LOADM statement 

¢ Data delimiter (/$ and /*) job control statements 

You can alter the default conditions by using the optional parameters. By choosing 
the optional parameters, you can use a specific printer, a certain scratch file, a 


specific file containing the load module, etc. 


For more information about the jproc call, refer to the Job Control Language 
Programming Guide (UP-9986). 
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v “A0Y TH8SdN 


€8 


UNISYS SYSTEM OS/3 LINKAGE EDITOR 
vaTe- 88/86/09 


CONTROL STREAM 


TIME- 


07.33 


4/ PARAM RLTBSOB UNOS 
4/ PARAM OUTS#ING 


43 


LINKOP NOA 
LOADA 
ENTER LIBS 





ENCOUNTERED AND PROCESSED AS FOLLOWS- 


1 
$e 
od9 


sesies KO3I-CONTROL CARD PLACEMENT ERROR 
bed aia! KOOS-ENTER OPERAND UNKNOWN 


INCLUDE 


LKIROOT, ORUMOS 


SRR Ss KO3I1-CONTROL CARD PLACEMENT ERROR 


SYMEOL. 


a0} 

401020¢ 
80103" 
ag? 

ac2020c 
AC?7O030€ 
A02050C 
ADCOOLE 
4C2080C 
AD2Z090€ 
4030108 
403030C 
ACSONTE 
403060C 
AC3O70E 
AO3090C 
AO3SIOOE 
AC3L2NC 
aO3230€ 
KES ALP 


4 


TYPE. 


cuecr 
CLEcT 
tNTRY 
C:ectT 
cseéct 
ENTRY 
Clect 
ENTRY 
ciecr 
ENTRY 
ENTRY 
crect 
ENTRY 
CSECT 
ENTRY 
CSECcT 
NTRY 
CSECcT 
ENTRY 
ENTRY 


PHAS 


RooT 
ROOT 
ROOT 
ROOT 
FOOT 
POOT 
ROOT 
RocT 
ROOT 
Foor 
Por: 
ROG: 
ROOT 
ROOT 
ROOT 
ROOT 
Root 
ROOT 
ROOT 
aBs 


INCLUDE . 
INCLUOE 
INCLUOE 
INCLUDE 
INCLUDE 
INCLUOE 


te. ADORESS. 


0000117 

COOOO3EC 
ooooo4s . 
FO0O118L 
co00i22 

00001 36 

o000089- 
oo0014c4 
OO001 S&L 
cooodlere 
O0000eF C 
GO0007B: 
Q000092e 
OGOOO9Fe 
oocooaTc 
ooooocs. 
OCOOOOF i 
cooooeDc 
goo0108- 
QO00016F 4 


LOAD MOOULE 


013A01010C,A010200, A01030C ,A0IO8OCS, OBUMOS 

A022 A02050Ca, OBUMNS 

A03,0BUMOS 

40134018, 0BJH0S 

AGZTANZO80C , AN2Z030C, ADZ020C,AN2010C ,ADZS, OBUMOS 
AO2ZAN2090C , A02080C, ADO2070C,AN2Z060C8,OBUNOS 


*DEFINITIONS DICTIONARY® 
SYMBOL. TYPE. PHASE. ADDRESS. 


aozyoy0c CSECT ROOT 00000358 
A01020€ ENTRY ROOT ocoo04seR 
aQ1080C CSECT ROOT oo000s00 
4a02010C CSECT ROOT 00001168 
A02020€ ENTRY ROOT co00012c4 
a02040C CSECT ROOT 00003370 
AO20SDE ENTRY ROOT o0000640 
ao2070C Csect ROOT ooao14cs 
ao2080E ENTRY ROOT 00001634 
A03 CSECT ROOT ooa0064s 
403020C CSECT ROOT 00000700 
AO3030€ ENTRY ROOT oooo08ec 
A03050C CsecT ROOT 00000930 
a03060€ ENTRY ROOT o0g00ab0 
ao3sos8oc CSECT ROOT o0000880 
AOSO9OE ENTRY ROOT noooooic 
a03110C CSECT ROOT oooooors 
A03120€ ENTRY ROOT QooocoF As 
a031480C Csecr ROOT 00001090 
KESRES ENTRY ABS OOO016F4S 


®@ ALLOCATION MAP ee 


= $“1000 SIZE - o000016F4 


4CL00130 
JCLO0140 
Jcino150 


JCLNOI60 


JCL00170 
JCt 90180 
JCL00190 
4CL 00200 
YCLO0210 
JCLNO220 


SYMAOL. TYPE. 


AOlOICE ENTRY 
a01030C CSECT 
AQIOSDE ENTRY 
aAD2010€ ENTRY 
ao2c30c CSECT 
aO2040E ENTRY 
ag2neoc CSECT 
AO2070E ENTRY 
ad2090C CcSECT 
a03010C CSECT 
aO3020E ENTRY 
ao3040c csect 
ADSPSOE ENTRY 
ag3o70C csect 
AO3080E ENTRY 
ao3100C CSECcT 
aQ3IIOE ENTRY 
403130C csecT 
AD3ISOE ENTRY 
LKIROOT CSECT 


Figure 8-2. Link-Edit Example 1 (Part 1 of 3) 


PHASE. 


ROOT 
Roor 
ROOT 
ROOT 
ROOT 
ROOT 
Root 
ROOT 
ROOT 
ROOT 
ROOT 
ROOT 
Root 
ROOT 
ROOT 
ROOT 
ROOT 
ROOT 
ROOT 
ROOT 





vER7T70503 


ADDRESS. 


o0000%0C 
00000470 
ooacossn 
00001220 
000012CA 
00001418 
00001418 
00001578 
00001638 
a0000650 
00000780 
ano00*%70 
oogoosEC 
o0000aR8 
coo0ncss 
oooooneo 
ooooorcc 
oooco* Bo 
00001170 
00000000 





sojdwexy weisoidg 





y ASN Tb88dN 








PHASE NAME TRANS ADDR FLAG LABEL TYPE €SIo LNK ORG WIADOR LENGTH Ogu ORG 
¢«100000 NODE - ROOT eoooo0an O00016F$ OOOO16FS 

eee START OF AUTO-INCLUDED ELEMENTS - 

oe —ND OF AUTO-INCLUDED ELEMENTS - 


- 88/07/02 11.49 - LayRooT OBy 
LMTROOT CSECT o1 oooc0000 00000353 00000354 ocooonon 
- 88/06/27 12.23 - aol OBJ 
ao1010C CSECT 02 oo000 358 ooo0030F oooo00ss oocoonce 
ao1020Cc CSECT 1€ oo0003E0 ooondser cooooosc ooo00090 
ao1030¢ CSECT iF 00000470 ocooo4Frr oooaons0 oo000120 
ao1080C cSect 20 oocoosoo oc000s93 00000094 60000180 
A01010€ ENTRY 02 0000030c ooooonsc 
401020€ ENTRY aE oooocess oo000118 
a03O30E ENTRY iF oooooeFc ooocoolac 
A01040E ENTRY 20 oooo0s90 o0000240 
- 88/86/27 12.25 - aod2 oBy 
ag20soc csecT 21 ooco0s9s oo00064s3 oocoooac ooo00298 
adg20Soce ENTRY 21 oogo0eso ‘ n0c0034en 
- 88/06/27, 12.28 - aa3s o8y 
aos csect 02 ooootess oooctes9 ocoo0002 onoooo0c 
a93010C csect 02 ooo006sa oooov6FF ocooo0Rd oooocoos 
ao3020C CSsEecT 1€ 00000700 00000783 doo0cos 4s ooooones 
agz030C cSsEecT iF 00000758 oooooser ds000068 00000170 
ao3s080c csect 20 oocooe7e oo000092A oooooosBe oo0002728 
ag30S50C Ccsect 21 00000930 oOocoosEF ooocooca oo0002te 
a03060C CsecrT 22 ooo00sFO oconoass ooooo0cs 00000 sas 
ao3o70Cc cCSECT 23 oooooase ooocaB7* ooocoocsa oooces70 
ao3080C CSECT 24a ooocorso ocooocsa oooccocc 00000538 
ao3090Cc CSECT 25 ooocecso cooooolF oooooco0 000004608 
ao3100C CSecT 26 acooon20 o0ooconrFs oooco0ns anooo6o0s 
a031310C Csect 27 QoOCODFs OooooECcF ocoocoos 00000760 
ao3%20Cc cCSECcT 28 oooooroo OOOOOF AB ooooo00c ocoorosss 
a03330C csect 29 oooooF BO oooo10sF cooocord c0000°68 
a03380C csect 2a 00001096 00003173 O0COCOE® cooooass 
A03010€ ENTRY 02 ooooasFrc ocooo0ss 
AaO3020£ ENTRY 1€ 00000780 o000016# 
AD3030€ ENTRY iF ooooosec 00000228 
AQ 3040E ENTRY 20 oo000928 ono002e0 
AQ30SOCE ENTRY 21 OOOOOSEC O0000 Sas 
AOSOGOE ENTRY 22 cocooaso oo00c0s6s 
AG3OTOE ENTRY 23 aoooor7c oconos 34 
ag 3080E ENTRY 24 oooocces . oco00600 
AQ 3090E ENTRY 25 ooooonic ooco060s 
AO3100€E ENTRY 26 ooocooro ocoooco7as 
AO3110€E ENTRY 27 GooooECcc ooco0o0 sas 
AO3I20E ENTRY 2s ooocooras 00000960 
4031 30€ EnTRy 29 o000308Cc 00000 a4 
AOSISOE ENTRY 2a 00001370 ooooces2e 
- 88/06/27 12.23 - aol oBu 
aol csect . 01 00001178 00001179 ooocooce2 oooo0o000 
~ 88/06/27 12.25 - ao2 o8u 
ao2 Csecr 01 00001180 00001358! ooooo002 aooo0000 
ao2010C csect 02 00001188 00001223 oocooosc ooooo000s 
a02020C CSECT aE 00001228 ooo0012c?7 oo0000a0 ooococoas 
ao2030c csect iF oocei2cs 00001368 ooo000a4 00000148 
a02080C csecT 20 00001370 00001417 ooocooas ooo001FO 
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sojdwexy weiss0ig 








Cc 

a) 

& HAGE NOME TRANS ANOR FLAG LABEL TYPE ESID LNK ORG HTADOR LENGTH OBU ORS 
402010€ ENTRY 02 00001220 coooonao 

ann au202ne ENTRY 1€ 000012¢c4 ooco0r44 

2 a02030€ ENTRY iF 00001 368 oocoo1rs 

< AOZ2040E ENTRY 20 000014814 00000294 

p - 88/06/27 12.25 - 002 Oey 
s02060C CSECT 22 00001418 o00014c7 ocooo0sn oooooses 
ao2070C = C SECT z3 oooniscs 00201578 oooo0ne4 00000 3F 
soz0soc CSET za 90001580 00001637 aocoo08s ooonn4en 
aoz090C = C SECT 25 00001638 000016F3 ooonoosc ooconser 
ag206c€ ENTRY 22 000014¢4 DO000tFS 
AO2Z2070E ENTRY 23 00001578 on00n4Kar 
AD2080€ ENTRY 2a 00001634 00000564 
A02090€ ENTRY 25 0000136FO oo000«20 

(4.000000 
FLAG CODES - 
- BLK DATA CSECT D - AUTO-DELETED E - EXCLUSIVE 2A. PEF 6G ~ GENERATED EXTRN I - INCLUSIVE wv. REF 
Lo - ULFE@REU LENGTH M - MULTIPLY DEFINED N - NOT INCLUDED P = PROMOTED COMMON R - SHARED REC PRODUCED 


- SHAPED ITEM U - UNDEFINED REF 
*AKY GTHER COLES REPRESENT PROCLSS ERRORS® 


LINK i PIT OF .SK1000. COMPLE TEO 
"ATE- 88/06/09 TIVE- 07.34 
ETRORS FNCOUNTERED- 000% UPSI- xX.00. 


ss TT eo OO OoO3 rm 


Vo- VCON ITEM 





Figure 8-2. Link-Edit Example 1 (Part 3 of 3) 
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sojdwexg weis0id 
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UNISYS SYSTEM O0S/3 LINKAGE EDITOR . vVERT70SOS 
NATE- 88/06/89 TIME 67.30 


CONTROL STREAM ENCOUNTERED AND PROCESSED AS FOLLOWS- 


77 PARAM RLIBSOBIMO: 
J/ PARAM OUTAENA 


ss 
LOAOM sai JC. 00130 
LINKOP NOA T JCLOO84O 
INCLUDE LKITROOT,OBUMOS JCL001S0 
OVERLAY A} JCL00160 
INCLUDE &013A01010C, AOLOZOC, ADIOSOC, ADIOS OCA, OBUMOS JcLo0170 
INCLUDE AO2Z2ZA02050CA, OB UMOS JCL00160 
INCLUDE A03,0B8UM0S JCL00190 
INCLUDE AOITAOIA, OBUMOS vci.00200 
INCLUOE AOZTADZOSOC ,ADZNSOC -AGZ2020C,A02010C , A028, OBUMOS JCL00210 
INCLUDE ADZ2ZAD2Z090C,ADZOBOC , ADZ070C, ANZ060CS, OBUMOS JcLo00720 
OVERLAY Al JCL00230 
INCLUOE 4013A401010C, AOILOZ0C, ADL O3SOC , ADIOS OCA, OBUMOS JCL00240 
INCLUDE AO2ZA02050CA,0BIMOS JCLa0250 
INCLUDE A03,08U"0S JCLO0260 
INCLUOE AO13A018,08NM0S JCLa0270 
INCLUOE ACZTADZOKOC, ANZ030C,ADZ020C AD2Z010C, A028, OB MOS JCLO0260 
INCLUDE AD2TADZ090C, ANZ08OC, ADZO7TOCS, OBUMOS JcLoo290 
ENTER A020 OC ycLoor%00 
SSee= KO30-.NTER OPERAND NOT IN CURRENT PATH 
se 


SUNRESOL VED REFERENCES * 


KLSOCP 
*DEFINITIONS DICTIONARY® 
SYM70L. TYPE. PHASt. AUORESS. SYMBOL. TYPE. PHASE. ADDRESS. SYMBOL. TYPE. PHASE. ADORESS. 
. 

ach Csect 01 “ 9000) 23u agi CcSECT 02 * 00001230 a01010C CSECT O1eveM Q0000410 
a03010C CsECcT 92 * coooo4i. acloloe Entry O1 * 00000594 AOIOlOE ENTRY 02 * Q0000498 
401020C CSECT Obevem OO00O49b aogi1o20c cSsECcT 02 * 00000898 a0l020E enrTRy O01 ® 00000520 
AQ1020€ ENTRY 02 ™ 9000052 aogza3oc CSECT O1¢vem 00000528 ao1o30c Csect 02 m o0000s28 
401030€ ENTRY OF ™ oocoosé4 AOLOSOE ENTRY O02 ® 00000584 agioeoc CSECT Oleven OOOCOSBS 
adioanc CSECT 02 ™ 0000056 AadiQ80€ ENTRY 0} ® 00000688 AG1O4OE ENTRY Q2 ™ 00000688 
aod2 csecT 01 ® 00001235 ao2 Csecrt 02 ™ 90001420 ag2z0130c CSECT O2°¥em G0001240 
ad2010C CSECT 02 4 0000123. AO2010€ Entry 01 ® 00003208 AOZ2010E Entry O02 * 00001200 
ad2020C€ CSECT Ol*vem QODOI2ZED ao2020C CcSECT 02 # 00001208 a02020E EwTRyY O1 ® 9000137C 
A02020€ ENTRY 02 *® 00001374 aog2030C¢ CSECY Oleven 00001380 a02030¢C CcSECT 02 ® 00001378 
a02030€ ENTRY O01 ™ 90001420 A02030€ Entry 02 m 900001818 a02080C CSECT Q1°¥4m 00001928 
agzo040c CSECT 02 ™ 0CO00142~ a02080E ENTRY 01 ® g000148CC aQ20e0€ ENTRY 02 ™ oo0018CcCc 
ao20s0c CSECT O1eVemM 00000650 ao2o0soc CSECT 62 ® 00000650 AO20S0E ENTRY 01} m oooooErSe 
AO2Z050E ENTRY 02 mM GOGOOSF « ao2060C CSECT O¢V* 00001800 aQ2060€ ENTRY Of 0000157¢ 
aozo70c CSECT O1eVeM 0000158U ao2070Cc Csecy 02 ® 00001400 aO2070E ENTRY 01 ™ 00001630 





Figure 8-3. Link-Edit Example 2 (Part 1 of 6) 
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vy A8Y TY8SdN 


£8 


aC2070b 
602080¢ 
An 2ng0c 
ar3 

ar 3o1oc 
ar 3a20c 
ac 3020E 
4030 30t 
A03040C 
4M3050C 
AD SOSOE 
Ae 30608 
4n3o70C 
ea30arc 
2C3OG60E 
AC3O096E 
4C3$100C 
A. 3120C 
Pr 7zblGe 
et 3120b 
£03130C 
6n5i40c 
P72 a0E 
KLENTS 
LKIRCOT 


ENTRY 
ENTRY 
Cec? 
C‘EecT 
CoECT 
CSECcT 
EaTRY 
tNTRY 
CcECT 
CSECct 
ENTRY 
ENTRY 
cect 
csect 
ENTRY 
tNTRY 
L€cT 
cect 
EATRY 
LATRY 
cect 
CSECcT 
ENTRY 
ENTRY 
CSect 


o2 " 
01 “ 
c2 * 
01 " 
02 " 
Olever 
02 " 
0} " 
a2 i! 
Oj} even 
02 " 
01 La 
02 La 
Chevem 
02 “ 
ol a 
02 bal 
Olever 
02 tod 
ar . 
G2 " 
O019Ver 
n2 Lal 
ROOT 

ROOT 


o0ag01S86u 
OrOOleEC 
DOU01b64~ 
00000704 
G0000786 
U0000TEs 
oooccses 
00000924 
ocooes2s 
UCcodosE 

OCOOOAAS 
cooocasér 
ocoo0os7. 
OOOOOC St 
o000000u 
ccgoouds 
oo000v0 

OGOOOEBL 
UOOOOF e4 
vooo1de. 
0000106 

uoools4&er 
Ubon 22 

vo00000u 
ocoooue. 


ao20860c 
ad2080E 
ADZ090F 
aos 
AO3OIOE 
ao3o20c 
AO3030C 
A03030€ 
AO3O40E 
aog30S50C 
ao3060c 
AaQ3O60E 
aQ3O7TOE 
ao30s8o0c 
a03090C 
A030905£ 
AOSIOOE 
a03330C 
aO03220C 
a03120€ 
A03130€ 
a03140C 
KESALP 
KLSOCP 


CSsecT 
ENTRY 
ENTRY 
CSECT 
ENTRY 
csecr 
CSECcT 
ENTRY 
ENTRY 
CSECT 
CSECT 
ENTRY 
ENTRY 
csect 
CSECT 
ENTRY 
ENTRY 
csecrt 
csect 
ENTRY 
ENTRY 
CSECT 
ENTRY 
EXTRN 


Oleven 
a2 Ci] 
01 U] 
02 " 
o1 Ci] 
02 Ll 
Oleven 
02 " 
oO. “ 
02 ” 
Oleyven 
02 i] 
0. " 
02 gd 
Oleven 
02 " 
01 4 
02 ca) 
Oleyen 
o2 ” 
ol « 
02 4 
abs 





00001638 
0000163C 
OOOO TAS 
00000700 
ooo00764 
oocon7B88 
c0000870 
00000924 
O00009E0 
OOOON9ES 
ooo004as 
00008968 
OO@00C 34 
oo000C33 
ogcoo000: 
ecoooons 
oooovE aa 
NooooFr so 
OOODOF 88 
oo001060 
ocoolies 
Goons 
000017aC 


ao2neoc 
ad2090C 
AO2090E 
ao3o10c 
A030)0€ 
ao3N20€ 
A03030C 
a03040C 
A03040€ 
AO30SOE 
a03060C 
ao3070Cc 
AOSNTOE 
AO3ONBDE 
a03090C 
a03100C 
AO3300€ 
AOSIIOE 
aodsi2nc 
a03130C 
AQDSI30E 
AOSIA0E 
MESRES 

KLSPTB 


Figure 8-3. Link-Edit Example 2 (Part 2 of 6) 


csect 
csecr 
ENTRY 
csect 
ENTRY 
ENTRY 
csecr 
CSECT 
ENTRY 
ENTRY 
csect 
Csecr 
ENTRY 
ENTRY 
csect 
csect 
Entry 
ENTRY 
CSECT 
CSECT 
ENTRY 
ENTRY 
ENTRY 
ENTPY 


02 4 
Oleven 
02 ) 
Oleven 
02 
0) 4 
02 " 
Oleven 
02 4 
01 “ 
02 Ud 
Olever 
02 i] 
oO} 4 
02 " 
Olevenm 
02 ” 
01 ” 
02 " 
O1sven 
02 " 
a3 4 
ABS 

ROOT 





oooorses 
000016F0 
oooodlers 
o00n0708 
oo00co7B% 
aooo0*6e 
00000870 
00000928 
ooc0o°EO 
ao000 sas 
onocoaas 
ooo009370 
Ooo000c 3* 
cooooroo 
ooooonos 
oooo0n0s 
oooooras 
OOOnoF ss 
Ooooor ses 
ononi%es 
OOCOl11464 
ooool122" 
0o00017AC 
onoo0des 





sojdwexy weiss0lg 





Program Examples 


(9 $0 € Wed) Z ojdwexy ypy-yur] “E-g eanBiy 
-_—— er ee eee eee EEE 


*J42E°20 I 


rw on en ew ww ww ne oe a re ne ee ee eee eet wee t 


5 *20"°00 1 


Oe - HS¥O HIV2 AG GIINISIUGIY SILAG XH SePUNLINAIS IBS¥Hdes 








t 

Fa 
a 
3 
a. 
= 





Program Examples 


aoocaco0 


s2,00000 
#nv0a0000 
09000000 
bes0co00 
vv.ooo00 
#0900060 
ousago00 
#¢5C0000 
39n00000 
mv<eoo000 
g3200000 
#220000c 
v9t(00000 
mguduool 
une 00000 
39000000 
98000000 
08200000 
gasac0g0 
60900000 
e£s00000 
02£0C000 
vv¢ 00000 
931¢0U000 
92200000 
oztoa000 
#8ooco00 
gougo0000 
oougo0uG 


Onz£Qu0u0 
goc0ogu0 


On2000UG 
d¥1Ga000 
wttaaod00 
Jeuocoun 
uetooooa 
o2taoou00 
geuooouad 
wououoco 


oouoodss 


9u0 rao 


2oc00000 


#3000000 
uji0000c0 
209000006 
gqgcooouG 
#coo00c00 
yoooo00G 
23000000 
83000000 
#3000000 
03000000 
yaooo00n0 
vac0o000 
n¥O00066 
ovo000090 
¢oo00000 


»voog0sco0 


"6000000 
06000000 
39000000 
9vd00Cc00 


Jef TaG00 


hsf00000 


30800000 
HLONIT 


(9 0 y Weg) Z ejdwexy Upz-yUr] “E-g eun3i4 


tg2togoo 


uz2toood 
ehTtugoo 
£90tuaod 
48 40000G 
a¥ 300000 
2ga0u000 
£Qugua00 
4£200000 
49900000 
4vvooo00 
43600000 
42600000 
89804000 
49200000 
tozouoco 


433900000 


of900000 
2as0c000 
£2s00000 
4600000 


uvitucoo 


ude0G000 


3000000 
aaaviny 


os2toooco to 
#2210000 v2 
bet tooo0 62 
o90too00 82 
#8300000 42 
ev300000 92 
#0000000 $2 
ooascooa L4 
#£ 200000 £2 
9000000 22 
avvoooo0 2 
03200000 az 
#2600000 st 
e9¢aq0000 at 
#8200000 20 
ehttoood v2 
y90toooo | 62 
98300000 82 
09300000 42 
eaquaceoo 92 
gouoo0o0co s2 
e¢£300000 h2 
oza00000 £2 
evvago000 22 
93600000 12 
#2000000 a2 
Ozsoaace st 
g92o0000 3 
#0200000 20 
00200000 to 
#3900000 1z 
osy¥0c000 12 
3900000 02 
#§s00000 dt 
o2sa0c00 at 
h6n00000 20 
e9s00000 02 
82s00000 at 
8600000 3t 
atego000 20 
oteooo0o 
#8000000 to 
oaoco000 
940 WNT QIs3 
Jvéztooo0 - 


ee 


13383 
rao 
AMLND 
AMIN 
AGINI 
ABIN 
AULN? 
AGILN} 
AMLN? 
AaLNG 
AULNZ 
AGINI 
ABLNG 
AMIN? 
AGLNI 
AMLNI 
13389 
13383 
£3359 
13389 
13389 
13383 
23359 
213359 
43389 
2133S) 
23359 
13359 
43359 
13359 
13383 
reo 
AGING 
12383 
rad 
AMLN3 
AGLNG 
ABILNG 
ABLNZ 
13383 
13383 
£3383 
1338) 
rao 


£3383 
ruo 


3dAk 


azIs 


aVH NOTAVIONIY oe 





tov 
tov - €2°2l se/oe/eR - 
2OetEg Ov 
30£ Tk OV 
302T£ OV 
JOtILoY 
a00TS OV 
3060f0¥ 
sOeocov 
3040f0¥ 
3090¢ 04 
30sof0¥ 
JOOS OV 
30£0¢ OV 
3020¢0¥ 
20tO£O¥ 
JOeteov 
dOL tL OV 
2OZLO8 
JOEOV 
2001£ OV 
2oe0f Ov 
dueoror 
JOLOL OV 
2090804 
Josotay 
Jonusov 
Jororov 
dozoror 
201 OV 
cov 
£ov - g2-2b 22z/9e/ee - 
30$020¥ 
dasozo¥ 
cue - $2°2t 22/9/88 - 
3J0nOTOV 
30¢Ut0" 
30Z010¥ 
30TOTOYV 
JOKOTOYV 
dorotov 
2ozotov 
Jototoy 
tov - §2°2t 22/90/88 - 
lv - JUN raooot«. 
e3yqca0ono 
LOOuEyT 
10001 "1 - 69th 26/20/88 - 
- SENQW373 AGSONTIINI-OLNY 40 UNG wee 
- SLN3W3I13 GIONIDNI-OLNV 4O LYVIS ee 


1004 - 109N ooonntix. 
138v1 Ov14 saggy SNVval IWYN JS VHA 
aootus - 31N00wW O¥01 
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O18 


jem 
g 
— 
S 
= 

bh 


—_—_——_—_— ea tere epnnyyerennnnaninnenevrenenstane 


PHASE NAME TRANS ADDR FLAG 
- 88/06/27 12.25 - 


- 88/06/27 12.25 - 


gacoos10 
“w 160002 NUDE - 4) 
88/06/27 12.23 - 


- 88/06/27 12.25 - 


- 88/06/27 12.28 - 


LABEL 
ao2 

ad2 
a02030C 
ad202cc 
aod2030C 
aO2040C 
ag201GE 
402020E 
AG2030€ 
AD2040E 
ac2 
A02060C 
a02070C 
ag2080c 
ag2c90C 
Ag206CE 
AQ2070E 
80 2080E 
A02090€ 


Ag} 
4013010C 
a01020C 
aolO30C 
a01040C 
401010€ 
A01020E 
A010 30€ 
AO1IO4OE 
Aad2 
402050C 
4020S50E 
403 
A03 
AQ 3C10C 
a0302C0C 
43030C 
AO 3N48NC 
403050C 
4c 3C€NC 
4C3070C 
86 5IC 
A03090C 
ao3100C 
ay31'te 
AU3Si. 
A0323%C 
403180C 
AC 3C1OE 
403020€ 
SO 3D30E 
+O3040E 
aG3OSOE 
a0 3060€E 


TYPE 
of” 
CSECT 
CSECT 
CSECT 
CSECT 
CSECT 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
oRky 
CSECT 
CSECT 
CSECT 
csect 
ENTRY 
ENTRY 
ENTRY 
ENTRY 


oRU 
CSECT 
CSECT 
CSECT 
CSECT 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
oPy 
CSECT 
ENTRY 
O8J 
CSECT 
csect 
CSecrT 
CsecT 
CSECT 
CSECT 
CSECT 
CSECT 
CSECT 
cSsect 
csect 
CSECT 
CSECT 
CSECcT 
CSECT 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
ENTRY 


ESIO 


Qo. 
02 
iE 
iF 
20 
a2 
1E 
iF 
20 


22 
23 
24 
25 
22 
23 
24 
25 


02 
1E 
1F 
20 
Ge 
lt 

iF 
20 


21 
21 


oO} 
02 
1E 
iF 
> 

<1 
22 
23 


25 
26 
27 
28 


ea 
C2 
1€ 
1F 
20 
21 





LNK ORG 


60001238 
00001240 
000012E0 
00001380 
00001428 
00001208 
0000137C 
90001420 
ao0o014scc 


00001460 
acoc1580 
20001638 
OO0001FFO 
o000157C 
a0001630 
GoooL16EC 
00001748 


00090410 


90000410 
o00004%98 
ooo00s2s 
20000868 
g900n0494 
00000520 
ooo00se4 
30000648 


aoaooesa 
ooocoers 


00000700 
o00u00708 
0000788 
00000870 
00000928 
J00009ES8 
Ooo0daAs 
oago0870 
00000C38 


ooocopos® 


ooooc00s 
“O00E8O 
DOOOOF BR 
00001068 
00001148 
00000784 
aoco0ses 
oo000924 
oocoo9Eo 
OGOGOAA4 
on000B68 


MYAaOOR 


00001239 
00001208 
OOOO137F 
ocno1a23 
OOooO14 CF 


0000157F 
00001633 
OOOOIGEF 
oooci7aer 


ooot1erR 


00990497 
00000523 
00900587 
go0co64s 


GOOCO6FS 


00000701 
00000787 
ooorases 
00010927 
OOOD09ES 
OOONOAAT 
oooroRes 
ao0on0gc37 
ononooo3 
ooo0co07 
OOOCOEAR 
OOOdoF a7 
00001063 
Cagcl’ 47? 
00001228 


Figure 8-3. Link-Edit Example 2 (Part 5 of 6) 


LENGTH 


oooco002 
ooooonsc 
coocaoao 
o00000A4 
oooco0as 


oooo00Bb0 
s00cocshs 
oooooors 
oocoodsc 


ono00ie: 


sagcocean 
anaoocec 
oo0000090 
ocoooces 


oos00nac 


onoooco2 
agocooso 
oooo0084 
90000088 
ooonoosc 
coo0ec0co 
cooooocs 
ooooooce 
ooocoocc 
ococoooa 
.o000004 
90000008 
no00000c 
cocooo°o 
aoogooES 


OBU ORG 


oocoono0oe 
aooo000s 
ooooconas 
aogoolee 
ocoosIFO 
oooo00a0 
ooocorss 
aoooolEs 
00000294 


00000348 
Oo0cOtFB 
oooocosRo 
aooooser 
GOO0O3F4 
ocoogvas 
ooo0ns64 
Co000bet 


ooocon0a 
o0000090 
02990120 
000001R0 
anonoo0sc 
00000118 
o90001AC 
90000740 


00000258 
00000340 


ocooonco 
00000908 
oogoones 
oooco179 
oo000228 
000092E8 
ongoo3aar 
00800470 
o0000*38 
oo000c0608 
oocouepe 
00900760 
o0g00888 
00000968 
co0000a4s 
oocconBbs 
00000168 
oooca224 
Oao002E0 
ooooo3a4 
00000464 





sojdwexy weld01dg 


PHASE NAME TRANS ADOR FLAG CAREL 

AOSOTOE 

AO3O80E 

AGO3O9OE 

AO3IOOE 

AO3I10€ 

403120€ 

A031 30€ 

AO3IGOE 
- 88/06/27 12.23 - Aol 
aol 
- 88/86/27 12.25 - ao2 
A02 

AaO2010C 

#02020C 

ao2030c 

AQ2040C 

AC2010€ 

a02020F 

AD2O3NE 

AO2040E 
- 88/06/27 12.25 - a02 

ao2070¢ 

ad02080C 

a02090C 

AO2NTOE 

a02080€ 

a02090£ 


v AMY Tr88-d/N 


00001400 


& - BLK DATA CSECT 0 AUTO -DELE TED 
L - DEFERREO LENGTH Ll MULTIPLY OE FINED 
S$ - SHARED ITEM u UNDEFINED REF 


*ONY OTHER CODES REPRESENT PROC‘SS ERRORS® 


LINK EOIT OF .Sk1000. COMPLE TED 
GATE~ 88/06/89 TIME- 07.32 
E®RORS FNCGCUNTERED~ 0002 UPSI- x.00. 


TYPE 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
OBy 

CSEeCcT 
oby 
CSECct 
CSECT 
CSECT 
CSECT 
CcSsect 
ENTRY 
EnTRY 
ENTRY 
ENTRY 
ORV 
CSECT 
CSECT 
CSECT 
ENTRY 
ENTRY 
ENTRY 


Esto 


23 
24 


26 
27 
28 
2 
2a 


0) 
0} 


iia 
VF 
2c 


1€ 
F 
20 


23 
24 
2s 


24 
25 


LNK ORG 
cocoac 34 
oooo00c0 
oooocnos 
OOOOOF Aa 
OOQOOF B84 
00001060 
0000114646 
00001228 


00001230 


00001420 
00001238 
00003208 
00001378 
00001428 
006012L0 
00001374 
00001818 
00001acc 


00001 4%cC0 
000015868 
60001640 
00001580 
0000363¢ 
oo00lére 


FLAG COOES - 
€ - EXCLUSIVE 


N - NOT INCLUDED 
vo - VCON ITEM 


oe REF G - GENERATED EXTPN 
Po - PROMOTED COMMON 


HIADOR 


00001231 


00003421 
00001203 
o00n1377 
o000)4)e 
ooooiscr 


ocoo01s83 
oooniesF 
aoooleFrB 


LENGTH 


oooo0002 


o0000002 
so000c0er 
aoocao0a0 
So0000A48 
o00000a8 


ooo0caBs 
ooooccss 
oncoo0ec 








OBY ORG : 
o0000534 
acocoso0 
ooccos0e 
ooo007sA 
coccoses 
0000060 
oooc0AKs 
ono0ce%28 


ooo00000 


oooococe 
ooooaoce 
oooooras 
o0000148 
oooac0dliro 
ooooo0a0 
o0000144 
ooooolEes 
00000294 


on0003F8 
ooocosse 
oco00ser 
ooooouas 
ooo00s6s 
ongegr2n 


1 - INCLUSIVE .V. REF 
R - SHARED REC PRODUCED 


SS a ee ea eT 


Figure 8-3. Link-Edit Example 2 (Part 6 of 6) 


Il 


sojdwexg weis0ig 








ele 


UNISYS SYSTEM OS/3_ LINKAGE EDITOR VER770503 
DATE= 88/06/09 TIME- 07.28 


CONTROL STREAM ENCOUNTERED AND PROCESSED AS FOLLOWS- 


// PARAM RL IBHOBUMO. 
4/7 PARAM QUTHIN@ 


s 
LOAOM ~TLNKOOO JCLN0140 
c----KO16-LUADM NAME INVALIO 
INCLUDE LKIROOT,OBUMOS sciao1s0 
OVERLAY CTLNKO JCLO0160 
-----KOQO-FGOT PHASE OVERLAID 
INCLUDE 401%401010C,AD1020C, ADIOSOC ,ACIONOCS, OBUMOS JCL00170 
INCLUDE A02%A020S0C8, 0B NMOS JCL00180 
INCLUDE A03,08NmM0S JCLO0190 
INCLUDE A03}2a018,08UM0S JCLOc200 
INCLUDE AOZZA0Z040C, ADZOSOC , ANZ02Z0C,AD2Z01GC,A0Za, CBUMOS JCL00210 
4* 


A[2060C sAUTO-INCLUDED*? 


*NR: SOLVED REFEPENCES® 


KLENCe 
SDEFINITIONS DICTIONARY®? 

SYMOOL. TYPE. PHASE. ADORESS. SYmePOL. TYPE. PHASE. ADDPESS. SYMSOL. TYPE. PHASE. ADDRESS. 
202 cect Cl 90000f2. ao1010C csecr Oievs gooc0000 AQINIOE ENTRY 0} oocoones 
#€3020C c:ect Oleve gooocoes ag1o20€ EntTRy 0) 00000110 -ag1a30c Csect Greve oogo0olrs 
C10 30E ENTRY QO} coocolat aoiosoc cSEeCcY Gievs g00001A8 adIOSGE ENTRY 0) 00000238 
#02 c:ect Gl GOOOOE2: ao2010c GSECT Giev*s. noooge 30 a02010€ ENTRY Q1 ooooorce 
te7020C CSECT Gleve QOOodED:. A02020€ Entry. Qt gooooréec ao2030C CSECT Oseve QoO000F70 
0 ON 308 ENTRY O01 coooigle ad2040C CSECT Gieve 99001018 a02060€ ENTRY O21 ooooinec 
322080C CSECT Oleve gogno246. afh2050€ EnTRY OF ao0002E8 ao2660C CSECT ROOT oooo0o0ar 
a02060€ ENTPY ROOT 00000154 ag2070C CSECT ROOT 00000158 aAQ2070E ENTRY’ ROOT ooo00208 
#92080C CLECT ROOT yoood2io a02080F ENTRY ROOT ooooo2cs ao2090C CSECT ROOT Q0o0o002ca 
ACCOSOE ENTRY ROOT oooon 381: aos csect O12 oaooo2Fo ao3010c CSECT Qievs gogoo2Fs 
aC 3O1OE ENTRY O1 000003a4 403020Cc CSECT Oleve gQng003a8 aO3020E ENTRY O18 oa0000ss5A 
463030C CSECT Cievs goocoKe. AOSO3CE ENTRY O62 oocoos14 ao3na0c CSECT Oleve goocesis 
s77040E EnteRy O01 Qooa0soL a030SOc CSECT Oleve go0000SD8 agsosoe entry 0) goo006s48 
403060C CSECT Gleve go000e9t AO3060E entry O01 oaoo07se ao3070C CSECT Olevs o0000760 
407070€ ENTRY O01 ao0000824 ao3o8oc CSECT Oleve oaooocezs ag3sosoe ENTRY OF ao000*FO 
403090C CSECT Oleve QooodsEFs AO3O9DE Entry 02 oooo0scs a03100C CSECT Oleve goooos9ce 
4031008 ENTRY 0} QNCOOAIS a03110C CSECT Oleve go0000AA0 aO3310E ENTRY O18 cooooP 74 
403120C CECT Oleve Qo0ddB?7< 4031 20€ Entry O11 ooocecso ao3)30C CSECT Oleve Qoaooocss 
4031 30€ ENTRY O1 oooo0ns. #03280C Csect Olevs oog000038 AD3190€ ENTRY O1 oooo0r18 
MESALP ENTRY ABS gooo1occ KESRES ENTRY ABS oao010co KLSNTS ENTRY ROOT oocooo0co 
KLEOCP EXTRN ~~ ercccee- KLSPTB ENTRY ROOT OOSDOOAS LKIROOT CSECT ROOT 00000388 





Figure 8-4. Link-Edit Example 3 (Part 1 of 4) 
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Program Examples 


(y J0 2 Hed) € ejdwexy ypz-yur] “p-g eun3i4 


arr er 


"os0Te tn 


OF = HSvO HIVI AG GIANISJUdty SILAG XIH SH PUNLINGIS Vivdger 
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go Og a ag i y 
im °o 
> ** ALLOCATION MAP #0 va 
Ln | 
LOAD MODULE -  CTLNKO $1z— -  900010C0 | 
CHASE NAME TRANS ADDF FLAG LABEL TYPE €siIo LNK ORG HITa0OR LENGTH OBY ORG 
cTLnKera NoDe - ROOT 90000000 oporas0s = ao00ne0c My 
eee START OF AUTO-INCLUDEO ELEMENTS - a 
- 98/06/27 12.25 - ao2 ofy 3 
ao2meoc CSECT 22 o0000088 c0000157  ccocDD8O aocnnses 
aoz070C CSECT 23 00000158  oo000208  oco0c008"  cdccoao%re a3 
aoz0e0c = CSECT 24 ago0c210 oo0002c7 00000088 = aon00%e0 © 
aozosoc = C SECT 25 ooo0n2zcs on0c03e3 oooco78c § =—-_- gn000568 n 
ag2060E ENTRY 22 00000154 OO0003F4 
AD2070€ ENTRY 23 p0000208 ogon04ae 
a0208°e ENTRY 24 oono0zce oooonses 
ac2090€ ENTRY 28 20000360 00000620 
‘ee €NO OF AUTO-INCLUDED ELEMENTS - 
- 88/07/02 11.49 - LK 1ROOT ory 
LK1RO0T = CSECT a) 00000388 o0c00608 90000354  op000c00 
cu00ds Ks 
cTLNKLO] NUDE -  CTLNKO oooco00e §=9—- sooo10BF — ononiocn 
= 88/06/27 12.23 - aatl osu 
ag1O10C © CSECT oz oao000c0 §=— sononee7 oov0so8® «= onoconos 
Ag1o029C csect TE go0o01n08s 00000313 aooocos’ onoconsa 
agi030C = CSECT iF 00000118 0000147 30000090 onane120 
s0108CC  CSECT 20 0000148  an00023" ononone4 oronorso 
AD 1010€ ENTRY 02 ooooc0es anooonsc 
&O0102CE ENTRY 1€ oo0000}10 G9000118 
ADIOZOE ENTRY lf ocoooias o90001aCc 
aD104%0E ENTRY 2 o0000238 vs000240 
- 88/06/27 12.25 - ao2 oBy 
agz0S0C csecT 21 g0000240  oo00002E8 ocooocat = =—-0000298 
a02050€ ENTRY 21 o00n02£8 oo0ca t40 
- 88/06/27 12.28 - 203 ory 
Aa3 CSECT 0} aoooozFo  can002F! oncoo002 = cooooran 
AD3O10C CSECT 02 ooo002F8 = gn000347 ococoved §=—ogoronos 
a03020C CSECT 1€ oo0003a8 ooo004se  acoo0084 poooonas 
AO303GC = CSECT iF 90000860 o0000517 cocoDgBs 00000170 
a03040C CSECT 2c s0000s18 ooo00so3 osoocosc o0o00co72aA 
ag30soc CSECcT 21 oooo0spa oo0nnes7 ocogococa oocoozEs 
a03066C CSECT 22 ooooness ooor075e noocoocs OOCOOOZAB 
403070C CSECT 23 oo0co076G onc00827 ooooonca o0c004870 
an3osoc = CSECT 2u opo00828 © o0n00eF3 oooocece §=—-_: 00000538 
Ag3090C = CSECT 25 coooorrs gonrosc? arocoonn  onocne0a 
ag3100C  CSECT 26 odoo0%cs oonaoage oeoo00Ds acoooeoes 
A03119C CSECT 27 oococaad ooonos77 oocooo0s onoo00780 
403120C CcSECT 28 00000278 oooo0cs3 oocooonc gooooAnss 
A03130C CSECT 29 aooo0ocss ao0o0r0037 oooooore oco00%968 
AO3I40C  CSECT 28 oo0000038 00000E1A DOODGOES goodoaas 
AQ3010€ ENTRY 02 o00003A45 ooooones 
Au 3020€ ENTRY 1e 00000858 ooo00168 
40 3030 ENTRY iF 000005146 00000224 
A 3040€ ENTRY 20 o0000s00 000002E0 
AQ 3050£ ENTRY 21 oo000698 00000344 
Ag 3060€ ENTRY 22 00000758 ooo0046R 
A03070E ENTRY 23 ooo00s24 00000834 


Cc 
g 
ny 
e 
= 

‘4 
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THASE NAME TRANS ADOR 


b ARN TH8SdN 


- 88/86/27 12.23 
- 88/06/27 12.25 


cvuooco00 


f - BLK DATA CSECT 9 
L - DEFESREO LENGTH " 
{o> SHAPED ITEM vu 

€ 


*ENY CTHER CODES REPRESENT 


FLAG LABEL 
a0 3080€ 
AQIO9OE 
AO3I00€ 
AO3I10€ 
AO3120€E 
A032 30€ 
AQ3180€E 
Ao? 
ao} 
ao2 
ag2 
ag2010C 
4a02020C 
a02030C 
a02040C 
a02010€ 
au2020€ 
AQ2030€ 
A02040€E 


AUTO -DELETED 
MULTIPLY DEFINED 
UNDEFINED REF 
PROC. SS ERRORS? 


LINK EDIT OF .CTLNKO. COMPLE TLO 


TATE- 88/06/09 TIPE- 376¢5 
EFRORS FNCOUNTERED- 0003 


cate a aaa 


SI8 


uUPSI- xX.00. 


TYPE Esto 
ENTRY 26 
ENTRY 2s 
ENTRY 26 
ENTRY 27 
ENTRY 28 
ENTRY 29 
ENTRY 2a 
OBy 

Ccsect 01 
OBY 

csect 01 

csecr G2 

CSECT 1€ 

cSsecT Fe 

csect 20 
ENTRY a2 
ENTRY 1E 
ENTRY 1F 
ENTRY 20 

FLAG CODES - 


Fo- EXCLUSIVE 


N - NOT INCLUDED 


vVo- VCON ITEM 


LNK ORG 
goocosFo 
ooo0o9cs 
oooocase 
oooogB74s 
ooooocso 
00000034 
ooooccels 


ooooor 20 


OOCOOF 28 
O0000E 30 
aoooofoo 
ooooor 70 
00002018 
goooorce 
OOOOOF 6c 
00001010 
-0000108C 


REF G - GENERATED EXTRN 
P - PROMOTED COMMON 


HI acOR 


oo0d0E21 


oooo0e29 
ooocoEcs 
ocooorer 
90001013 
sooo1oeF 
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LENGTH 


ooocoaa2 


ooooc0s2 
ooooo09c 
opooocan 
ocoo0cdas 
Ocoocoar 


TI - INCLUSIVE 
R - SHAREO REC PRODUCED 








OB ORG 
aocoos6ca 
gococeDs 
oocoo7as 
ocooorss 
oacoc%6o 
OoooD Ass 
cosoos2s 


aoooococo 


G0000700 
ooooonoe 
ooo000as 
00000148 
ooooaliFo 
oooonta0 
10000144 
aoooo1Es 
GO0002948 


Ve REF 


sojdwexy wess0id 








UNISYS SYSTEM OS/3 LINKAGE EDITOR VER770624 
DATE- 88/07/08 TIME- 07.45 


918 


CONTROL STREAM ENCOUNTERED ANDO PROCESSED AS FOLLOWS~- 


4/7 PAPAM RLIB#OBUMNOS 
J/ PAPAM OUTRING 


“gs 
LOAOM SK) 
LINKOP NOCUT 
INCLUDE LKIROOT,OPUMOS 
OVERLAY NODEO) 
INCLUOE AOSZANSOICA,OBUMOS 
OVERLAY NODE D2 
INCLUDE AOSRANSO2CA, OBUMOS 
OVERLAY NODE O3 
IwCLUOE AOSEAOSO3Ca,OBUMOS 
OVERLAY NOUECS 
INCLUOE ADSTADSONCA, OB UMOS 
OVERLAY NODE OS 
INCLUDE AQS%AG5O5C@, OBUMOS 
OVERLAY NODE 06 
INCLLOE AOSTADSOGCS ,OB UNOS 
GVERLAY NODE G7 
INCLUDE aCS2a05N7CA, 0B UNOS 
OVERLAY NOGELS 
INCLUGE A0S3A9D508CA,OBUMOS 
CVERLAY NODE LO 
INCLUDE 405240509Ca , 0B NMOS 
OVERLAY NODE IO 
INCLUDE A0STA0SIOCa, OB UMOS 
OVERLAY NODE 11 
INCLUDE aCS2A0511C@,08UM05 
OVERLAY NODE 12 
INCLUDE A0S3A0512C8,08UM0S 
OVERLAY NOOEI3 
INCLUDE ACSZAOSI3CAa,OB UNOS 
OVERLAY NODE 14 

veins KOO2-NUDE FOINT LIMIT - 34 PER PATH 

INCLUDE A053A0514C@,08UM0S 
OVERLAY NODE 15S 

ae 


*UNRESOLVED REFERENCES* 


#01010€ AQ1020€ £01030c A01080€E a02010€ a02020€ a02030£ AO2040E A0205 O& a02060E 
AO2Z070E AQ2080E A02090F AO 3010€ aG3020E A030 30E a03080€ aOSOSOE A0306 OF AO3070E 
AOZOSOL AQ3090E aC3100; A031 10€ a03120€ A031 30€ AO3140E a01010C ao1020¢ a01030C 
A01080C 402010C ac2020c ao2030C ad2080C. a020S0C a62060C ao2070Cc a0208 0c ad2090C 
a03010C 403020C ao3o3ac ag3080C ad3o0soc a03060C ao03o070¢ ao3080c a03090C aosioce 
4O32120C 403120C ao3130¢ a031480C 


*DEFINITIONS DICTIONARY? 
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5 
3 
: 





sojdwexy weis0idg 


v ARY Tv8SdN 


L18 


SYBMKUL e 


a0103G. 
eoEO2ce 
AOVGNEC 
soro ot 
£0.030C 
AU 2D4CE 
AUZOLLCO 
BOCETAL 
EL COOLL 
*C ORCL 
4CS03CU 
wsaNLe 
Perdeue 
ACTOTCE 
40 709GC 
eC eUUe 
ac rpect 
@ 7y$ck 
sso’ 
ander 
<O504¢ 
ACh OSt 
a°SoOrc 
AUSOBL 
EUSTLC 
AveLet 
AUST SC 
ansvas 
LKTROOT 


TYPE, 


trTRt 
L>TRN 
EXTRN 
ErTPR 
LXTEN 
taTRK 
RO TRA 
Crietn 
EXTEN 
Lx TRN 
cxTen 
cATRN 
EXTEN 
tx TRN 
EXTEN 
Lelin 
ExTRA 
taTRN 
Cel 
ENTRY 
c:tct 
EKTPY 
cect 
LntPey 
Ccect 
ENTRY 
c.ect 
ENTRY 
Csect 


PHASE. 


--eye 
-- aye 
~ceve 
--aye 
--aVe 
--eye 
--9Ve 
~-aye 
eve 
0) 

O° 

3a 

cs 

o7 

CR 

10 

1 

13 

14 
ROOT 


ADURESS. 





uCCOO3+8 
COGDL372 
GGONG 3c 
OCCOU3cE 
OCLOG3' & 
coGd04.2 
Ooooo4K4es 
Looon4 6 
uooonsLs 
LOcoo3:2 
vocoooco 


SYMBOL. 


ADIOIOE 
A01030C 
AQ1OSCE 
ac2G62uc 
a02030€ 
ad20scc 
AC2UEDE 
aozoaeoc 
AGZO90E 
ao3c20c 
AaO3030€ 
a030S0C 
AO3O6CE 
ao3080c 
AO3090E 
aqs31oc 
A031 206 
AOSI4CC 
AOSOIE 
a0so3c 
AQSOUE 
40506C 
AOSG7E 
AOSLOC 
acsive 
aosi2c 
A051 3€ 
KESALP 


“TYPE. 


EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 
tXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTan 
ExXTRN 
ENTRY 
CSECT 
CNTRy 
CSECT 
ENTRY 
CSECT 
ENTRY 
CSECT 
ENTRY 
ENTRY 





ADDRESS. 





Q00003SE 
00000378 
000003A2 
oo0o03cs 
00000406 
00000438 
00000492 
ooco004ba 
000005 3F 
00000542 


SYMBOL. 


ao1020c 
AODLOSOE 
ao2010C 
ac2020€ 
ao20s0c 
A020S50€ 
ao2070C 
AO2N80OE 
ao30i0c 
acsneoe 
ags0soc 
aO3CSOE 
ao3070C 
A03080E 
aosyooc 
aOSIIOE 
A03135C 
AOSI4OE 
4oso2c 
AOSNSE 
aososc 
AOSOGE 
ao5oac 
AQSCIE 
ao533C 
AQSI2€ 
aOsiac 
KESPES 
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TYPE. 


EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 


“ EXTRN 


EXTPN 
EXTRN 
EXTRN 
EXTRN 
cXTRN 
EXTRN 
EXTRN 
csect 
ENTRY 
CSECT 
ENTRY 
cSECT 
ENTRY 
csecr 
ENTRY 
csect 
ENTRY 


PHASE. 





AODRESS. 





CON00 368 
30000 386 
00000 saa 
On000 E2 
000004810 
ooooosse 
ooocosea 
ooocosc2 
00000358 
00000542 





sojdwexg weis0idg 








+ 

Fy 
a 
3 
a 
> 


(G J0 € Wed) } edwexy upz-yUrT “¢-g eun314 


a an a a ee 





: ecfeoo 7 
cageet 1 
Joweee 
snes I I 
I I 
‘weto © 
I- 
°a°20 T 
I- 
ezteso 
I - 
ooteno I 
I-- 
verso I 
I-- 
°ateoa f 
I -- 
*zzttu I 
I-<- 
*9z°a0 1 
[o--- 
svz°6o I 
” I --- 
& eaz°ot 
Qa wenn 
£ aeee 1 
Ss togeatt 
I---- 
c *weest 1 
« 
be Q ~ HS¥O HIVI AB O34N9S9UG34 SILAG KIH S|FANIINGIS BVHdee 
a 
© o 
a. rs) 


YAY TV8Sd/N 


618 


PHASE NAME 


$«100000 


LOAD MODULE 


TRANS ADOR FLAG 
NODE - ROOT 


$x1000 


LABEL 


eee START OF AUTO-INCLUDED ELLMENTS - 


eee END OF AUTO-INCLUDED ELEMLNTS - 


sx1G0001 


3K1G0002 


s*300003 


s¥}UOGO4 


$41u0005 


$K 100606 


$”x190007 


sx1gocoe 


$K 100009 


88/07/02 11.49 - 


cvooeo00 
NOGE - NOVEOI 
88/96/27 12.42 - 


0G000354 
NUDE - NODEC2 
88/06/27 12.42 - 


2500C36- 
NUDE - NODECS 
88/06/27 12.42 - 


JGO0037*% 
NCOE - NODEOS 
88/06/27 12.42 - 


Cucoo390 
NODE - NOUFOS 
88/06/27 12.42 - 


30c003A5 
NDE - NOUVEDS 
88/06/27 12.42 ~ 


oceoo3ca 
NODE - NODEOT 
88/06/27 12.42 - 


OO00003E8 
NODE - NOGEDa 
88/06/27 12.42 - 


00000410 
NUDE - - NODEDS 
88/06/27 12.42 - 


00000% 38 


Lx }ROOT 
LK 1ROOT 


aos 
agsoic 
agsale 


aos 
aoso2c 
AQSsO2E 


ags 
a0so3c 
AOSO3E 


aos 
aoso4c 
AOSOSE 


aos 
aososc 
AOSOSE 


aos 
4oso06c 
AQSOGE 


aos 
agso7c 
AOSOTE 


aos 
agososc 
aoSOse 


ads 
adsogc 
AOSOSE 


#* ALLOCATION MAP oe 


SIZE - 


TYPE 


O8u 
CSECT 


Ofu 
Csect 
ENTRY 


oBy 
CSECT 
ENTRY 


OBu 
CSECT 
ENTRY 


OBy 
csect 
ENTRY 


oBbv 
CSECT 
ENTRY 


ORY 
Csect 
ENTRY 


. 08s 
CSECT 
ENTRY 


OBu 
CSECT 
ENTRY 


o8u 
CSECT 
ENTRY 


Esto 


02 
02 


03 


oa 
oa 


os 
os 


06 
06 


o7 
a7 


38 
as 


og 
09 


oa 
OA 


00000882 


LNK ORG 
ooooc0ca 


soocon0e 
00000 358 


aooca 356 
00000 35E 


00000 368 


00000 368 
00000 372 


00000 378 


00000 378 


00000 366 . 


Go0000390 


00000390 
00000 3A2 


00000 3a8 


OO000 348 
00000 38E 


60000 3c8 


00000 3c8 
00000 3E2 


000003E8 


00000 38 
Qo000 %06 


00000210 


00000410 
00000832 


oooc04sse 


o00004%36 
Oo0dosSsE 


HIADDR 
oooo003ss3 


90000353 
00000361 


00006361 


00000375 


00000375 


00090389 


ooc00389 


g0000345 


o00co3a5 


oo0003¢c) 
ooo003c) 


OOOOO3ES 


OOOOOSES 


cooo0sc9 


ooo004809 


00000435 


00000835 


0000063 


90000%6) 
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LENGTH 
00000354 


oooce3s4 
oooooooa 


oocooooa 


oooooo0Ee 


ooooondE 


oc000012 


o0000012 


ocoo00l6 
ooo0cdls 


no0000i1a 


O00000IA 


OOCOOOIE 


oooooole 


oooeso22 


ooo000022 


ococ00z6 


oo000026 


ooo0002za 
ooooco2s 








OBS ORE 


ooooonaa 


ooocooos 
oo0n0%0E 


00000018 
00000922 


oooo002s 
oco00036 


oooo004o 
ooocens2 


ooooo0ss 
OOGCODGE 


ooooonze 
00000092 


goooco009s 
oocooors 


aoooo0cco 
ooo0ove2 


oooocoEs 
OOO0010E 





sojdwexy wes301g 











vt 

> 

@ 
a 
3 
a 
2 


(S 0 G Yed) y edurexy Upz-yurT “¢-g eun3i4 





*OO°K -ISdN 9550 -O34N31NNOING S¥ONd? 
6h°L0 =30Ti 90/20/88 -31¥0 
931310n0) *OOOtwS* 40 1103 WNIT 


*SU0UE2 SSIIOUd LNISTUGIA $300) BIH10 ANVS 








W3LI NODA - A 438 G3NTJIONN - A WILT Q3avHS - 5 
Q39NGONd 334 O3uWHS - 8 NOWMOD G3L0N0Nd - ¢ Q30NIINT LON - N | G3NTS30 AIGILINW - w ~HIONIT 3809970 - 7 
438 °AS GAISNDNE - I MGAK3 Q3LV¥INI9 - 9 9 49d CVS JATSAIIKG ~ 3 0313730-91n¥ - 19353 vivo wig - 8 
- $3009 9v13 
g6£o0000 
USVHd HLONZT O83Z STOOOTWS-220"----- 
oooocase ®6¢ 00000 St300N - 300K stooates 
«seacono 
zezo0000 z6£ 00000 so AWLNG antsov ; 
@stoo000 = agggc000 = secagn0n §=—s es. 00000 40 133530 Detsov 
rao Sov > 272 aesoe/ee - 
3¢000000 seto000o = ¢ss 00000 “300M - 300N #toootws 
yosooa00 
3300000 3€500000 30 AMIN 3190" 
setogooe §=§=— vgo000a0 tesoo000 = eos. 00000 30 19332 JEts0v 
rao sov - 272 se/se/eR - 
¥£000000 tesoo0co0 = aes 00000 £U300N = 30°N ¢ToontNs 
00200009 
29100009 z0sQu000 ao AwLNa 3Z1SOV 
Getcoooo = ss 000020 soso0000 «= dae a0000 aa 49382: SztsOv 
: rao sov > 29°%h ez/oe/ee - 
” 9000000 soso0000 ods0ac00 20300N = - 209K ztoootys 
® 86800090 
a 94100000 99800000 20 agin attsav 
£ Ssteo000 §=9=—zgco0000 = 6 "0000 600000 20 19382 0-3 Isov 
rao sov - 27% 2e/9e/ee - 
s zeoo0000 = 6 3800000 = #6 ep0000 {1300N — - 300N trooorss 
a #9800000 
z¥t00000 26800000 ao AwLN] 201sOV 
E @tto0000 =. azog0000 se¢e00000 «© #9n.00000 ao 19352: 2atsov 
© rao sav - 272k cesve/ee - 
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Program Examples 


PROMOM SO Z20 FNM 194920 BINT ¥S4 OS 





(pT $0 T Wed) g ejdutexg upz-yur] “9-g eun3iy 








FO CHOW OZ0HdIS WISITICINND FONTINI 
$8300 AV18 3A0 
PO OKOW *O60HdIS WIEITLG3 NT 20NT WHT 
PO OHON*OOLHdIS WIGITICINNT JONI INT 
£5300 AV¥S INO 
PO ONGH ORHsIS WISITICINNT JONI INT 
@u2ac AVTEIAG 
PO OWON SO ROHAIS WIBITL0I NNT WNT INI 
62300 Av14 300 
PO OHON SOTSHdIS WIEILICINNA JONIINI 
O1u3A0 avila 3a0 
PE ONONO9ONdIS WI8DTIOINNT FONT ING 
O1wzao avia3a0 
PE OHGN OT THAIS WISITIOI MNT 3007 WE 
oteaao aviw Jao 
PE OM SELONdIS WIFITIGINNT JONTINI 
642A0 avis 300 
PS OHOM OSOHGIS WIGITIOINND JONTINI 
Z *U3A0 AVIEIA0 
PO OWGN @bT Hass WIGITAOINNT JONTINI 
40300 AVTB 3AO 
FO OHOM *O60OHdIS WIOITIO2I NNT FONT INI 
PE OHOM OCR HSS WIBITSCIMNT 20NI DHT 
240300 AV1u 300 
CO ONOM ZT HIS WIBITICI MNT 30NT IAI 
OU3A0 AVIuIA0 
TO OHOM PLONE WISITICI MND ONT INI 
40200 AvIu3A0 
FE OHOM ROT HSIS WISITAGIMND JONIING 
@B2a0 Avia 3A0 
PR OHGHCITAGINNTOII“ZOINND FONT II 
$U3A0 AVIa3A0 
FROMAM RT LAGINNTEMTICT NNT FIND INI 
suza0 avila 200 
FROMM OTL 05 1°1d LO INN TSN GI NNT 30NT NT 
eU3A0 AVE 380 
FROMM AVS LOINNIBYIIGINNT JONTINI 
£43A0 AVIS IAD 
FO OHOM TO VIAGINNTSY IOI MAT JONTINT 
28200 AVIEIAO 
FROMM OSE TOV DIGI WN ONT WT 
tU2A0 AVIV IG 
WITLI B3Ln2 
FO CHAM ENTACINNTSNILOINNT JONI INT 
S¥ILGINNTSY 2203 JONI INT 
FR OHONOdS WET 3102 NNT IONTING 
THIAO AVIU 300 
2039" 83403 
FEONOUPR 10 2NNI8¥I1032NND FONT INT 
FEOHOM*RT LOINN TAY IOI NNT IONTINI 
CEONGNTUSASES ZONTINI 

OBI WIT 40 WHITES L5G? LS31 UIBNTT OF 706 e 


OLNVON GORNITT 
2030R1 HOVE) 


ss 


FOOMANTE TIA VEY 47 


-SAOTIOR S¥ 037S5 390Ud ONY G2UIINNOINZ NV3BIS TOuLNOD 


9O°xt - ania 90/20/88 - s1vO 
WOLI03 3DVNI1 £/SO W31SAS SASINN 
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—_—.0 OO RL SE 


OvE MLAY overs 
INCLUDE LYK EDTICSLA SCPHO 34, ROMO BU 
OVERLAY OVE RE 

INCLUDE LNNEDOTICOLK SCPH1S3, ROMO BU 
OVERLAY OVERS 

INCLUDE LAR EOTI C8Ln SCPH1 33, ROMO BU 
OvERLAY OVERS 

EMCLUDE LON EOTICOLK SCPHNS13, NOWOBY 
OVERLAY OVERS 

INCLUDE LONEDTICSLK SCPHS28, ROHO BU 
ENTER Laseause 

OVE atav OVERS 
1m LUOE LNE OTIC OLESCPNS 38,n ONOB 
Ove Miay overs 

INCLUDE LAMM EDTICOLK SCPH 368, RONO BS 
EMTER LRSCPHIG 

OVE Riay OVE Re 

INCLUDE LYK EDT CELK SCPH 178, RONDO BU 
CaTER Lascrmre 

OVERLAY OVERS 

INC LUE LWRE OTIC SLESCPH1 G8, ONDE 
ESTER LUSCPHIB 

OVERLAY OVERS 

INCLUDE LIME DFICSLK SCPHS62, ROHO BY 
ENTER LASCPHSE 

OVERLAY OVERS 

INCLUDE LMR EDTE COLA SCPHS72, ROWO BU 
CUTER LRSCPNS? 

OvE MLAY overs 
Twc LUE LMRE OTIC OLAS CPHS 82, DHOBY 
ENTER LKSCPHSS 

OVERLAY OVERS 

INCLUDE LKSM19L NSA) 3,.40n08U 
OVERLAY OVERS 

INCLUDE LASUOLK S¥0, NDHOBS 

OvERLAY OVERS 

INCLUDE LASWISLKSd53,NONOBU 

OVE @LAay OveR2 
INCLUDE LASNELK SNA, MOHOBY 

CNTER LUSH 

OVERLAY OVE RZ 

TMCLUDE LASLLAS TODA TALNGA,N OHO8 US 
INCLUDE LASLLAS TOLKSLLASTS, MOHO BU 
ENTER LRSLLAST 

OVERLAY OVER2 

IMCLUDE LASLLAS T8904 TASH Ta, R DHOB UD 
IMCLUOE LASLLAS FOLK SLLAST@a, ROWOBY 
EWTER LRKSLLAST 

OVERLAY OVERS 

INCLUDE CHSLLAS TOLASTIZ 18,4 OHOB 
OVERLAY OVERS 

TMCLUDE LASLLAS TELASTOT HA, NM DHOBY 
OVERLAY OVERS 

INCLUDE LASLLAS TELASTPHS3,NOHOB J 
OVERLAY OVE RZ 

INCLUDE LKSTOLK STa, NOHOBI 

OVERLAY OVERS 

INCLUDE LNKEDIC ASLK $Pa, NOHO BU 
INCLUDE LNKEDTCASLNKEDTCAd, MONDE 
INCLUDE LASMELK SH,LKS523,."0H0BU 
ENTER LKSA 

OVERLAY OVER? 

INCCUDE LESASLK SH23,"DHOBU 

RES x°a20° “IN TRL SPACE 


ccs 


sojdwexy wesZ0lg 
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Cc 
g 
— 
wz 
oy 

s 

7 








PANN Te88dN 


E28 


StRBOL. 


DATALNG 

Orscons 

oPscone 

DPSCOn? 

LASTOTN 

Leesuser 

teesuss 

LascospPc 
LK SC OFPC 
LKSCPHOS 
LX SC PHOS 
LKSCPHOD 
CaASCcPHIL 
LKSCPHIS 
LascPHIT 
LASC PHA) 
iN SC PHS 
LKSCPHS? 
LXsCPoRe 
LASCRFPC 
UKsCunNFP 
LKSCUMPC 
LA SCUPCF 
LK SOBINC 
LasocHar 
ixs00.n 

ixs016CcO 
LasonooPp 
Lasoopsc 
LASDSCNA 
LK SOSCHI 
14 SE ALOF 
LKSEBOLB 
CLMSE BORF 
Ln sé CSM 
Ln SE ONOP 
4K SEENLA 
LK SEEOPE 
UKSEINGL 
CASE T WUC 
UNSELBDE 
LK SE LNNE 
LA SE RNOF 
LH SEMPSL 
UN SENCUP 
LK SE WODL 
LK SE WORN 
NSE WOSR 
tx SE mous 
UK SE ORNF 
LSE OVOP 
LSE PNO 

LUSERTIO 
ix SESTBD 
LASEMTYP 
LKSFRLA 

i SI0320 


TYPE. 


cSec# 
ENTRY 
ENTRY 
entry 
CSEcY 
ewrey 
ENTRY 
ENTRY 
Entry 
Csect 
CSECE 
CsEcT 
cSECU 
cSEct 
csect 
Csect 
csect 
CSECT 
ENTRY 
ENTRY 
ENTRY 
Entey 
Enrry 
Entry 
entry 
Enrey 
Entry 
entry 
entry 
Entry 
Entey 
Entry 
EnNTRe 
entry 
Entey 
ENTRY 
entry 
Entry 
Envev 
Entry 
Entry 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
Exvay 
Entev 
Entry 
Curry 
EuTRy 
Entre 
EnTRy 
ENvRe 
ENTRY 
ENTRY 
Entey 
Entry 


ass 
ABs 
aes 
aes 
ass 
aBs 
ass 
aBS 
ass. 
ABS 
ass 
ass 
ass 
ass 
08 


ADDRESS. 


0000 OF 58 
60000030 
ooo00090 
00000030 
0000 1620 
O000 1568 
o0a0 1868 
0000 18 
0000 18680 
0000 19£8 
00002250 
0000 1070 
0000 2250 
0000 1010 
0000 13€0 
0020 1956 
00002268 
0000 13EO 
o0000cso 
00000680 
0000 19c0 
0000 1998 
G000 16C0 
00000030 
00000092 
00000032 
00000000 
00000030 
00000006 
an000098 
000 0002 
ooo00ese 
go00003F? 
ooo00038 
ooooocr?T 
oooo0003Cc 
oooo O1cE 
0000 01DE 
ooaoasrs 
0000 06E1 
00000158 
oo000083 





_ 0000 021E 


000006FF 
0000 o3ec 
00000190 
00000852 
opoo008s 3 
00000512 
00000237 
ooo00783 
0000014 
00900010 
00900098 
00000373 
0000 061¢ 
0000 1F82 


SOEF INET IONS 
SYMBOL. TYPE. 
DATASHT csecr 
OPSCON2 ENTRY 
DPSC ONS En tev 
RESALP Entry 
LASTPHS CSect 
Leosuse cntay 
tUSCOIFL ENTRY 
LescosPpc ENTRY 
LASC PHI] ENTRY 
LxscPnae CSECT 
LKSCPHI7?) CSECT 
UnscPna9 CSECT 
LKSCPHI2 CSECT 
LKSCPHIS CSECT 
LKSCPHI8 CSECT 
UKSCPH82 CSECT 
txsceHsl CSECT 
LKSCPHSS CSECT 
LASCPPCA ENTRY 
LRSCRPCA ENTRY 
LKSCUMFP CN TRY 
LUSCUPCA ENTRY 
AKSCUPCF ENTRY 
LKSOBTAN ENTRY 
LKSOCHOF ENTRY 
LAXSDESDA ENTRY 
UKSOLIBS ENTRY 
UXSONESP fNTRY 
txsorDsl ENTRY 
LKSOSCNC ENTRY 
LKSOSTSC ENTRY 
LESEBCAT ExTRY 
UKs€so.0 SN rRe 
LKSEBDSN ENTRY 
LKSECSNO ENTRY 
LKSEENCR ENTRY 
LKSEENLA ENTRY 
LRSEEQPH ENTRY 
LMSEINVO ENTRY 
LOSE TVPN ENTRY 
LMSELMLBE CN TRE 
UKSEMIVO ENTRY 
LKSENOPR ENTRY 
CRSENTOL ENTRY 
UXstwOe =O EN TRY 
UMSsENOOP CN TRY 
LKSENORS ENTRY 
UXSENOTE CNTRY 
LESEOPAS ENTRY 
Uxs€owa® ENTRY 
LKSEOYRG ENTRY 
LXSEREGM ENTRY 
LKSESLIG ENTRY 
UKSETSOF <M TRY 
LK SE XNO ENTRY 
LASILOND ENTRY 
LKSIO380° «ENTRY 





OIC TI ONARYS 


PHASE. ADDRESS. 


39 
root 
RooT 
abs 


oo oon sa 
10000000 
00000000 
90002590 
00 001620 
00002568 
o0c00998 
00001818 
on0crsEs 
00001010 
00002168 
o000010%0 
ooco2008 
o0001880 
000013€0 
oooolsce 
00002250 
OO 0013EO 
ooocor7ca 
000006 18 
o000019CO 
00002698 
00 0016C0 
oo oo0000 
00000000 
00 000006 
ogo000000 
00000002 
oo 000008 
00 000002 
Go c00008 
00 0006S5C 
00 0006 32 
00000 3Cca 
00 0001 30 
oo goazes 
G0 000003 
ooo0oiFO 
000002 7c 
ooacosce 
00000188 
00 0002 3E 
oo 0002Cc7 
o0000030F 
009000 2F 
ooo00051 
oo00052F 
00 00032C 
G0 QOD0 AE 
00000748 
00 00078C 
OO D0006E 
00 000708 
00 00066c 
00 0000E1 
00002280 
OO0DIF6&e 


‘SYWBOL. 


OPtc ono 
OPSC Ons 
OPSC ONG 
RESRES 
LASTEXT 
Lassuss 
UxscorFr2 
LK SC OF PC 
CKSC PHOZ 
LKSC PHOS 
LaSC PHOS 
LKSC PHIO 
LKSC PHI 
LK SC PHI6 
LSC PHSO 
LESCPHRS 
LKSC PHS6 
LKSC PHTO 
LK SC RE PC 
LKSC RTPC 
LKSC UMPC 
LUSCUPCA 
LUSOBERT 
LXSOCALP 
LXSOCONP 
UKSOBTCT 
LKSDAHOR 
LKSONS TK 
LKSDSARC 
LKSDSCAM 
LKSOURRC 
LNSE BOC] 
UKSE BOLI 
LKSE BPAR 
LSE CSHP 
LKSE EWEX 
LKSE EWPC 
LKSt Tum 
LXSE EVDE 
LASE LASH 
CASE LARS 
LKSE RNDE 
UR SE RPOL 
LSE NTNA 
LKSE WOSZ 
LKSENOPH 
LK SE NOSC 
LXSE MOTF 
LASE OPRN 
tS OVER 
LK SE OVRT 
LK SE RNAL 
LXSE SOB 
LK SE UOBI 
UKSFAIN 
LX$I 0300 
44810350 


Figure 8-6. Link-Edit Example 5 (Part 3 of 14) 


TYPE. 


Ew rey 
Entey 
Entre 
Enter 
CSECT 
Enrey 
Enter 
Ewtry 
cSECT 
csecr 
cSECcT 
CSECY 
CSECT 
CSECT 
csect 
CsecT 
csecr 
CSECT 
ENTRY 
Entry 
ENTRY 
ENTRY 
EnyRee 
Entry 
Enter 
Entry 
Entre 
Entry 
Entre 
Entry 
entry 
Entry 
Enrey 
entey 
Entry 
entay 
EnrTey 
Entry 
En vey 
EnrRy 
Entry 
Entey 
Entry 
ENTRY 
EnTRy 
ENTRY 
Ew tere 
eEnrRy 
EnTRe 
EWwTRy 
EntRre 
ENTRY 
Entry 
ENTRY 
Enrey 
Entey 
Ewrry 








PHASE. ADORESS. 


Roor 
RooT 
ReoT 
ass 
a3 
o1 
ass 
o1 
21 
13 
a8 
o8 
2 
26 
mw 
27 
31 
20 
ROOT 
root 
on 
as 
ass 
ags 
aes 
ass 
ass 
aes 
ass 
ass 
aes 
ass 
ass 
ass 
ass 
ass 
ass 
aps 
ass 
ass 
ass 
ass 
ass 
ass 
ass 
ass 
ass 
ass 
ass 
ass 
ass 
ass 
ass 
ass 
ass 
os 
a1 


80300000 
90300000 
9030 0000 
00302090 
00 30 1620 
0030 late 
903007Cce8 
00301890 
G000 1968 
0030 1F 28 
00302168 
0030 1¢50 
00301880 
0030 33£0 
0000 1020 
003019E8 
0030 13E0 
00302010 
903007C0 
00700796 
0000 1998 
0000 16 98 
00300006 
00303030 
0030900 
00300000 
0090 0005 
0030000 
0090 00 00 
003900032 
9073000048 
00200570 
003008 20 
ooo0 O6a7 
0090 05 a8 
00200724 
90200308 
0030080" 
00300112 
003000 9¢ 
0030 0968 
00300255 
0030 0%aC 
00300291 
00300391 
00200018 
0030 00 16 
003001 IF 
oo03000c8 
60300760 
00300033 
00300898 
00900702 
00000703 
9030063¢ 
DOIORF TA 
0030 IF 72 





sojdwiexy weisoig 





928 


Cc 
E 
— 
S 
= 

- 


LKSLENS2 
CASLPSTL 
LASL PTOV 
LKSn2 
UKsn 
1ase 
insu 

LA S48 AUSP 
UMXEDICA 
LMHEOTIN 
UNKEDIPT 
UNE OB) 
PHNOATIN 
PHNOCTAT 
PHMOPHO! 
PHNO PHOS 
PHNOPHO? 
PHNOPHIO 
PHEOPHIS 
PHNOPHS) 
PHNO PHS 
PHNO SPIN 
PHNOTXT 
PMOLASLE 
PNOLKSAI 
PROLAST 
PRUTA 
PRETRC 
PRSVSA 
s¥soau 


pn 


ENTRY 
EntTRy 
twiRey 
esecr 
csect 
CSECT 
CsEcT 
tnrry 
csect 
cSect 
Csect 
Csect 
Cwrey 
CNTRY 
Entry 
ENTRY 
turey 
ENTRY 
Entry 
cutee 
Cwtry 
CNTRy 
ENTRy 
curey 
Entry 
tntey 
Entry 
Eniey 
Cstct 
Entry 





o1 
ROOT 
os 


90000038 
Oooo 1Ese 
0000 £346 
00001250 
ooo0arss 
” 0090050 
b000 1186 
OOOO 19EA 
» ooo0GrSse 
0000 1958 
” 0000 $360 
ooocosee 
GOOOF 3F2 
oooor2Fé 
00000037 
00000009 
000000386 
00000038 
do000028 
00000025 
00000019 
OOOO FZF9 
0030 F SFO 
GoOoOFSFS 
oooOr IFS 
Oooo rSFS 
" ooo0aceSs 
"4 OQOOOOFIA 
00000090 
m 0000 16E8 


LMSLLAST 
LUSLPSTS 
Lasn 
LXSA2 
inse 
LKSSCRDL 
Lusul 
UNKE OT 
LNRE OTCA 
LNKE OTES 
LNKE OTSA 
LUNKE OT2 
PHNOATLE 
PHNO OTH 
PUKOPHI2 
PHNOPHOS 
PHNO PHOS 
PHNO PHI) 
PHNOPHIS 
PHNO PHS 
PHNO PHD 
PHUNOSPLG 
PNOLKSIN 
PNOLASLS 
PNOL KSAZ 
PHOLKSE 
PRETR 
PRNTARC 
ssca 
SYSRUN 


csect 
ENTRY 
csecrt 
cSEct 
csect 
ENTRY 
cse€ct 
csecr 
CSECT 
cSEecr 
csect 
cSsect 
ENTRY 
Entry 
Entay 
Cu tRy 
entry 
EW TRY 
Entry 
Cw tRy 
ewrey 
Enrey 
En sry 
EN try 
ew tay 
ENTRY 
Ew yey 
enrey 
cwtey 
Ewrey 


Root 
Root 


00001190 
OO GOOF 76 
000011368 
ococot so 
00 OOUE SO 
o00020aCc 
00001168 
00000818 
00 000F Se 
000019€8 
00001168 
00001568 
QO OOF 3F 3 
OO OOFSF) 
00000021 
00000013 
00000018 
00000015 
00000012 
00000026 
00000020 
00 00F SFO 
OOOOFOF! 
OO OOF 3F9 
Oooorears 
GOOOF3FS 
OODODEES 
00 GOOF 14 
ooaonese 
oooooree 


LESLLAST 
CKSLPTOV 
tusm. 
LKSMZLEN 
Lusp 
Lust 
(KS3PO9L 
LNKE OTCA 
LNRE OTIC 
LNKE OTPT 
UNKE OTSA 
LNGE DTZ 
PHNOATSH 
PHNO PHS 
PHNO PHOS 
PHNO PHI6 
PHNO PHO? 
PHNO PHIZ 
PHNOPHAS 
PHNOPHAS 
PHNO PHS) 
PHENO SPSH 
PUI ASTZ 
PNIL ASA 
PNOL ASH 
PHIL KSHD 
PRNIR 
PRETRC 
SvsoBu 


Figure 8-6. Link-Edit Example 5 (Part 4 of 14) 


csecr 
twray 
csecr 
EMTRY 
CSECT 
csecr 
ewrry 
CSECT 
csecr 
csEecr 
tstct 
csecr 
Entay 
Entry 
Enrey 
twtry 
tnwtey 
Entay 
twtay 
entry 
ewtey 
entry 
em vay 
Entey 
cwtev 
Entry 
cwtay 
entry 
Entay 


39 
38 
3e 
ass 
oz 
a3 
ass 
o1 
or 
O18 
o8 
os 
ass 
ass 
ass 
aos 
abs 
ass 
aes 
ass 
ass 
aes 
ass 
aes 
abs 
aes 
as 
aa 
08 





00202390 
00301386 
00301168 
0020096C 
00 20 DE SO 
00300F 58 
00300228 


oo 200r se. 


902 19€8 
0020130 
00 20 1168 
00301568 
OOIFSFI 


OO 20FSF2 


00309022 
00300016 
00200011 
0030 0020 
00309023 
90000027 
00200017 
OO30FZFS 
00)0FOFs 
OI FSFS 
OOIOFIFT 
OOJOF3IFE 
00300€ES 
Q0200F ta 
0030 16E8 





sajdwexy wess0lg 





Program Examples 
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~- 1 
e@veze I 1 
a 1 
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«022.00 IT 
{ecscece 
28¥,0€ I 
o8¥.6Z I 
oO4.0Z 1 
0037 £2 I 
ot total 1 
003Z.92 f I 
SSeeseS t 
1 2809.90 t 
Fovceeceawecs ioe 
e098 .S2 I 
009% UZ I 
058.90 I 


---- I 


0097.40 I 
o8G1,02 : eee 
wo2.00 3 
e8O2.T 
s04a.60 1 
eO9t.Ot pot 
erate 
oCET.6t es 
Teezser t 
083.01 oo 
ry Fry as qT 
--- I 
oO2,0T 3 
oO0t 091 r 
seez.st 3 
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Program Examples 


(pT $0 9 Yed) g ejdwexy upz-yur] “9-g ein3iy 


a ee 


0396058 


1 
a we www one - + oe ee ! 
if 


1 205 3.00 


eQ9tt.ic 7 


oOf6.E8 1 


To eoteeo 
I--- 
0899.85 I 
yatoee tf 
vous 
ae og Re Se 2899.6¢ i 
eOSsele poe eg 
OT oae.on i 
eee i ee 20d 9098 t 
tae 
0822056 1 oe 
er The 
eee 


+ 

Fs 
ce 
3 
a 
a) 
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Program Examples 
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(v1 JO £ Hed) g ejdwexy upz-yur] “9-g aunsi4 
pe a we a 





otzoocoo e9TT0Co0 ®s 400006 Zy37A0 = --«300N £00 2"NT 
es300000 
zedtoco0 vt 400000 wt Aain3 Ja Ahad 
Or2tocao @3 300600 vw Awana aimad 
ezatacoo ectoocoo @ss00coco Os 3Go000 v1 42353 asm 
rao ¥21039N1 - -e'8e 98/ze/zb 
ectaococ @s 40 0C00 Os 300006 TU3A0 = --«:200N Z0103mNy 
6361Co00 
westocoo zz stocoo zc AMAN3 OSfo Tsu 
32$tocoo 99 410000 2c Ae1N3 Osco ISNT 
OC of oc 00 04$00C00 @0 st aco 93610000 zc 42353) W110 39N7 
rao NWHiG 39NT - -erge ee/ze/z. - 
os e2oc00 81 ¢1 0000 at Aaind 3490 9847 
o¢zz0c00 93910000 at Auina reosas 
eorzocoo 02 910006 at AwINa 4240981 
ostzacoo #6 910000 at aaana VIdNIENI 
oso2z0coc e9S1 0000 at Amina asnc6@? 
@0 #2 0c 00 03610000 at ABAN3 Jun ISNT 
o@e20C 00 96610000 at 4ain3 Iduh ISH 
oecz0c0o 89¢t0000 at AUINI Ssnceat 
ese20c00 0® 910000 at Awan2 3440 98"7 
0802000 ecaocoo @3610coc s9stoooa at 22359 9210. 39ND? 
431 0C00 et 0Co0 e951 0C00 03st 0000 Pl 42352 1410 3567 
os 2tocoo @£z00C00 a3£1 oCoo e9ttoooo at 4338) vSi03%N1 
Oc OF oc OC orzgococ e9tt oco0 @s 400000 zc 42353) ¥31039N7 
reo ¥31039N) - eee 9e/ze/2L - 
zeoTaco0 vt 300000 I ain? 2a 1Nad 
Ot 3t oco0 #3300000 vt A31N2 alnad 
92 @T oc 00 ec toocoo @s 400000 os 300000 vw 13359 os 
reo ¥240 2907 - 46°88 98/Ze/2L - 
eettacoo saat ocoo 0s 300000 Tajo =—- =300N Taioawey 
eteoocooo 
otztocoo e£e00co0 0s 300C0C el goocce a 493589 103987 
rao ¥310 3901 - 46°98 eB/20/2L - 
evetaroo #3200000 ot AgANI Vdd I9NT 
ozetocao 02200000 6t aain3 3d38 98N7 
421 a0coG #6 200000 61 aaan2 24259507 
391 0C00 #9 900000 6t AuiMa woss 
ovetocoo o&% 900000 6t Autn2 34489507 
64 9t OC OO 81 900000 6t AUIND ¥3dy ISNT 
eestococ #3 e0c006 6t A@IN3 noesas 
est ov00 o£ 900C00 etaoocoo 93 e00000 ot 29382 11039N7 
reo v240 39N7 - be7ee ee/ze/tL - 
acococoo 00 ooo0 co zc AMIN] Sno 2840 
oc ooacao 00 ovoc0o zo AMINa 2uo 3840 
OC 06 oc 00 o00co0c0 zc AaIN2 no 2840 
oo ae otco oo ocooco z AwIN2 two 3840 
ocooacoo oo 000000 ze AvIN3 cCwo 2840 
ocooocon oooo0c0a 2 AM1N2 4402840 
OC 06 0c 00 00 oo 0000 2 awan3 £uo 2840 
ot 00 0c00 00 ococeo zc AwIN3 eno San 
o3s3 vs 
0c 00 oc oO 9380 0C00 9380 0C00 oo oco000 zc ae Neasae ieee gavue/en - 
©86 SAN3WI12 QIONIINI-OANY 40 GNI cee 
- SIN3W573 AIONTIINI-OANY 30 18 wis pis 
os300coo = os 300C00 §=—- n0 000000 FORE eo ae scaud 
suo reo 419N37 woo vin 380 ww a1s3 3dAL 138" svi voay sNval 


O60z0060 - 3z1s 1027 - wow aver 


oe d¥h NOTLVIOTI o@ 
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vy A8Y Tp8sdN 








PHASE NAME TRANS ADOR FLAS 
- 12/07/88 08.31 - 


ooooorse 
LNKEDTOS MODE - OVERS 
- 12/07/88 08.31 - 


00001168 
LNKEOTOS NODE - OVERS 
- 12/07/88 08.31 - 


oooo0r ss 
LNKEDICE NODE - OVERS 
- 12707/88 08.31 - 


00001 9ES 
LMKEOTO? NODE - OVERS 
- 12/07/88 @8.31 - 


LaBEL 
UNAEDTICA 
LNKE OTCA 


LNKE OTCA 
UNKE DISA 


LNKE DICA 
LNKE OTPT 
LNAE DT2 
LA SC OF PC 
Lassuss 
LKSC UMPC 
LKSC UMFP 
LB93USR 
LKSCUPCA 
LKSCUPCE 
sysoBu 
LSC OBPC 


LAKE OTIN 
UNE DTI 
LKSILDNO 
LKSSCMOI 
Uk820390 
L«s10320 


LNKE OTIC 
LNKE DTIC 
LMSDCALP 
UKSOBING 
LKSOCOMP 
LKSOSCNA 
ixsourrc 
LxSOR0B1 
LKSOBTRN 
LKSOCMOF 
LRSOSARC 
_ LR SDSCNC 
UKSDLIBS 
LKSOSCNA 
LKSOSTSC 
LXSOESDA 
LRSOSCHL 
LX SO MHOR 
LUSOCHAL 
LxsoOLn 
LKSDBEXT 
LKSOGTCT 
LKSC PHI 
LKS3PO9L 
LMSC PORG 
LKSO1BCO 
LKSONSTX 
LKSDWESP 
LK SO mODP 
LKSDOPSC 


TYPE 
OBJ 
CSECT 


OBJ 
csecr 


o8u 
CSECY 
CcSECT 
ENTRY 
ENTRY 
ENTRY 
EnTRY 
ENTRY 
EWIRY 
EnmRyY 
ENTRY 
ENTRY 


oBU 
cSECcr 
ENTRY 
ENTRY 
ENTRY 
ENTRY 


obs 
CSECE 

ENTRY 
EntRyY 
ENTRY 
ENTRY 
Enrey 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
Entry 
Entry 
ENFRY 
Entry 
Entry 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
EnTRy 
ENTRY 
ENTRY 
ENTRY 
ENTRY 
EWTRY 


ESID 


a2 


1B 


1c 
10 
1D 
10 
10 
1D 
10 
1D 
1D 
10 
to 


ac 
ic 
ic 
ic 
ic 


LNK ORG 
ooo0odF 58 
00001168 
90001168 
ao00!3€0 


000013£0 
00001568 
G000 1840 
GOGO 1868 
00001996 
0000:9CO 
aoa01s68 
0000 16 98 
0000 16CO 
Ooo016E8 
00001618 


o00019ts 


aoo019E8 
30002240 
oaoo20ac 
OOOOLF 7A 
ooo0 tF 82 


OOO0I9ES 


000019E8 
9090000 00 
gooco000 
00000000 
ooco0c02 
Gocco 0A 
ooaconos 
90000000 
oo000000 
ao003000 
a0000002 
900000900 
ooo0c00 04 
o00000 08 
000000 06 
aoo00002 
ooocon0s 
ooac0002 
000000 02 
000000 06 


“90000000 


Oooo 19ES 
oooo00z06 
o000nc $a 
00000000 
90000000 
00909002 
90000000 
000000 06 


Hrao0R 
0030 1168 
003013€0 
003013£0 
00j0 1966 


0030 1568 
0030 19£8 


9030 2280 


00302280 


0030 1¢S0 


0030 1¢50 


Figure 8-6. Link-Edit Example 5 (Part 8 of 14) 


LENGTH 
007300210 
00200278 
00300278 
00300618 


00300188 
00300980 


00300658 


00300858 


00100268 


00300268 


a 


OB ORG 


0030 1030 


0030 1c 80 


0030 IE F6 
00 30 2080 
00302356 
00302380 
003024980 
0030 2908 
00902080 
00 30 2180 
00302108 
00302230 
00302330 


o0302aF0 
00303348 
00 20 318% 
0030 30 82 
0030 3084 


90309000 
00303030 
00303030 
00300020 
00300092 
00300034 
00203038 
90203030 
90300030 
90300030 
00300002 
00 30 3030 
00300038 
90300034 
30300036 
00309032 
00300094 
00309092 
80302032 
00309036 
00300030 
00 300030 
00300208 
00300c SO 
00302030 
003009000 
00309092 
00300090 
00300036 





sojdwiexg wess01g 








¥ A8Y Tr8ed/N 
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PHASE NAME 


LNKEOTOS 


LWKEDTOS 


LOMEDTIO 


UNKNEDTI2 


LaEeorI2 


Laxeoris 


LKEOTIS 


iaxeoris 


LANEDTIG 


menor? 


LMKEOTIS 


LOKEOTI® 


ANKEOT2O 


LaKEOT21 


‘TRANS ADDR = FLAS 


00001 98 
MODE - OVERS 
12/87/88 08.31 - 


oo001cs3 
NODE - OVER? 
12/07/88 08.31 - 


00001013 
MODE - OVERS 
12/87/88 08.31 - 


oo00z008 
NODE - OVERT 
12/07/88 @8.31 - 


12/07/88 08.31 - 


00003013 
WODE - OVER? 
12/07/88 08.31 - 


0000101) 
MOOE - OVERS 
12/07/88 08.31 - 


ocoolIF2s 
NODE - OVERS 
12/07/88 08.31 - 


00002 168 
MODE - OVERIO 
12/07/88 08.31 - 


0003225) 


NOOE - OVER 10 
12/07/88 @8.31 - 


00092253 
WODE - OVER 10 
12/07/88 08.31 - 


6009225) 
WODE - OVER? 
12/07/88 08.31 - 


00002 168 
NODE - OVER? 
12/07/88 08.31 - 


00032 168 
MODE - OvVERT 
12/07/88 @8.31 - 


12/07/88 08.31 - 


00091013 
NODE - OVERS 


tasEL 
LKSCOIF! 
LKSC OIF2 


LNKE OTIC 
Lxsc PH10 


LNKE OTEC 
LKSC PHOS 


LAKE OTIC 
RSC PHIZ 


Unde OTIC 
LKSC PH30 
LMKE OTIC 
LXSC PHIS 


LacE OTIC 
LKSC PHAS 


UNAE OTSC 
LASCPHIS 


UNKE OTIC 
LKSC PHI? 


LNRE OTIC 
LKSCPHI1 


LAKE OTIC 
KSC PHOS 


UNKE DTIC 
UNSC PHS] 


UNKE DTIC 
LKSCPHIe8 


LWKE DTIC 
LUSC PHRE 


UNKE OTIC 
LxSC PH70 
LAE OTIC 
LKSCPHI9 


TYPE 
ENTRY 
Entey 


obs 
csecry 


08J 
cstct 


OBJ 
csect 


es8u 
csecr 
obs 
cCSECY 


oBy 
csecs 


o8u 
csect 


OBJ 
csect 


oBy 
csecr 


osu 
csect 


08d 
cSECT 


oBy 
csecr 


OBJ 
csect 


0B) 
csecr 
oBbJ 
csecr 


€sio 


30 
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Section 9 
Initialize Disk Routine (DSKPRP) 


9.1. Introduction 


Before using any disk or diskette, you must initialize it, a process commonly called 
prepping. You prep a disk or diskette when you evaluate the condition of the recording 
surfaces of your disks/diskettes and prepare them for handling the programs and data 
that you will later write to them. Prepping can consist of an in-depth evaluation and 
preparation of your disks and diskettes, a partial analysis of only a portion of your 
disks and diskettes, or an operation as simple as changing a volume serial number. 


Note: You cannot execute disk prepping to do a partial prep on an active SYSRES. 


Whatever the prepping function, you do it by using the Unisys supplied prep routine 
called DSKPRP. The disk and diskette types currently supported by System 80 and 


prepped by DSKPRP are: 

Disk/Diskette Removable/ System 80 

Type Nonremovable Models 

8416 disk _ Removable Models 8/10/15/20 
8417 disk Nonremovable All models 

8418 disk Removable Models 8/10/15/20 
8419 disk Removable All models 

8430 disk Removable Models 8/10/15/20 
8433 disk Removable Models 8/10/15/20 
8470 disk Nonremovable Models 4/6/8/10/15/20 
8494 disk Nonremovable Models 8/10/15/20 
8420 diskette Removable All models 

8422 diskette Removable All models 
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In addition to the DSKPRP routine, there is a standalone prep program (SU@PRP) 
which supports 8494/8470/8417 disks on the models 8 through 20 and 8470/8417 disks 
on the models 3 through 6. SU@PRP is used during system installation for disk 
formatting with defect skipping and surface analysis. SU@PRP creates a volume label 
for the prepped disk. Other prep facilities are available to you in the form of canned 
job control streams. These control streams allow you to change volume serial numbers 
and to prep and allocate system-resident (SYSRES) files. The prep canned job control 
streams are explained in 9.10. 


9.2. Prepping Your Disk 


92 


All new disks must be initially prepped before being used in your system. The only 
disk excluded from this requirement is the 8417 nonremovable disk. A surface 
analysis is performed as part of the manufacturing process for this disk and it is 
shipped preprepped to your installation. The only time you need perform an initial 
prep on an 8417 disk is when you encounter disk problems. 


The prepping procedure for all disks in your system is basically the same. It comprises 
two functions. The first is a track analysis in which each recording surface on the disk 
is checked for defective tracks. The second is a label initializing function where you 
build the initial records that must be written on the tracks of your disk before you can 
write data or programs to them. These initial records are the standard volume label 
(VOL1) and the volume table of contents (VTOC). 


The only difference in the prep procedures performed by DSKPRP on 8416, 8418, 
8419, 8430, 8433, and 8494 disks and on 8470/8417 disks is the action taken when a 
defective area is found. When prepping the 8416, 8418, 8419, 8430, 8433, and 8494 
disks, DSKPRP assigns alternate tracks/sectors for areas found to be defective. The 
defective tracks/sectors are then listed in a track condition table (TCT) or, for the 
8494, sector condition table (SCT). 


The 8494 has a physical sector size of 512 bytes. Each sector is addressable as two 
256-byte logical records. There are fifty 512-byte tracks/sectors and 10 
tracks/cylinders. (OS/3 imposes a logical view of the 8494 of ninety-six 256-byte 
tracks/records and 20 tracks/cylinders.) 


Alternate sectors on the 8494 are assigned on a sector basis (as opposed to a track 
basis, which is done for other devices). Each cylinder has five 512-byte alternate 
sectors, which are arranged to minimize the overhead associated with an I/O operation 
that spans a cylinder boundary. The alternate sectors reside on the last physical track 
(head 9) of even-numbered cylinders, and on the first physical track (head 0) of odd- 
numbered cylinders. In addition, alternate sectors are assigned so as to minimize the 
overhead associated with accessing an alternate sector. (The closest available 
alternate sector is assigned.) If a record is defective, an odd/even record pair (sector) is 
assigned to an alternate sector. The disk prep output listing always reflects the odd 
record number for a defective sector in an alternate assignment. 
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When prepping the 8417 and 8470 disks, DSKPRP first attempts to reformat the 
sectors on a track that has a defect. That is, it positions the defective area in the gap 
between sectors. If, however, several defects exist on a track and the track cannot be 
reformatted, DSKPRP declares the entire track defective and assigns an alternate 
track for the defective one. A record of the surface analysis, listing the defective and 
alternate track assignments, is then written to a table similar to the TCT. If the disk 
being prepped is an 8417 disk, then a second table called the defect skip table (DST) is 
also prepared. It lists the locations of all defects found throughout the disk. Both the 
TCT and the DST are explained in 9.3.10. 


The surface analysis performed on the fixed-head area of an 8417 fixed-head disk is 
the same analysis performed on the disk itself. If, however, a defective track in the 
fixed-head area cannot be reformatted and all the alternates are already assigned, the 
bad track is then deallocated. A track is also deallocated if the head that accesses it is 
bad. All deallocated tracks are listed in the track deallocation table (TDT) that is 
printed between the TCT and DST. 


In addition to using the track analyzing and label initializing functions of the disk 
prep, you can perform the following operations: 


¢ Prepping a specific track or a group of tracks 


¢ Prepping a specific track or a group of tracks and verifying that a file does not 
reside on the track(s) 


¢ Choosing options to specify prepping only, fast surface checking (fast prep), or an 
extremely accurate surface analysis 


¢ Replacing the volume serial number only 
e Adding both IMPL and IPL 

¢ Replacing IMPL only 

¢ Replacing IPL only 


¢ Creating a new volume serial number and a VTOC without performing a surface 
analysis 


¢ Indicating that the disk is to be used as an IPL volume 
¢ Checking the expiration date for all files 


Note: Before running a disk prep with a supervisor that is not configured to the 
specific system hardware, make certain that the drive for the disk being prepped 
is turned on. This reconfigures the information in the PUB. Otherwise, the job 
uses the current PUB information to determine disk type and features that may 
not be representative of the disk being prepped. 
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9.3. Specifying Prep Options for a Disk 


You choose the prep options by selecting one or more of the following keywords. The 
only keyword you must select is the SERNR keyword identifying the volume serial 
number of your disk. As many keywords as can be contained on one card are 
permitted (through card column 71) and as many cards as needed can be present in 
your control stream. Remember also, that keywords may be specified in any order. 


The format of the keywords is 


,ALTRK= (N , ILOPT= {i i IPLDK=Y on Model 8-20) 
yJt Wi) (when RPVOL=Y) 


,PREPT= 


tH 








/ANseT= (| ‘a {8) ote stan | 
“Cy tal 


bi (ia 





»PTEND= { cccchh 
019386 (for 8416 only) 
019312 (for 843@ only) 








80 (for 8417 only) 
F (for 8478 only) 
(for 8494 only) 
952786 (for 8419 only) 
032712 (for 8433 only) 
04030D (for 8417 fixed-head only) 
032786 (for 8418 only) 








SERNR=volume-serial-number |, TRCON={ 6 
K (for 8417 only) 


C,FRMTG=D (for 8478 only)] 
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eres A i 


D 
L 
% (for 8417 only) 


,VTOCE= { eccchh VERFY= { Wi ,/UNXFC= ft 
QBEAnN (for IPL volumes) Y Y 


(for non-IPL volumes) 


»TRKCT=(B (for 8417 only) ,VTOCB= { cccchh 
(for IPL volumes) 
(for non-IPL volumes) 











9.3.1. Testing Alternate Track Areas (ALTRK) 


As stated earlier, one prep function is performing a surface analysis of your disk. 
During this process, any defective tracks are flagged and alternate tracks are 
assigned. When you use ALTRK=Y or omit the ALTRK keyword, the alternate track 
areas of the disk are tested to ensure that all tracks are usable as alternate tracks. 


You can suppress the testing of the alternate tracks by using ALTRK=N. 


Note: Alternate track testing is not supported for 8494 disks. ALTRKE=N is always 
assumed. 


9.3.2. Prepping Your Disk as an IPL Volume (ILOPT and IPLDK) 


System 8D Model 8 through 20 Users 


You are required to write both the initial microprogram load (IMPL) and the initial 
program load (IPL) to your disk when prepping it as an IPL volume. You cannot write 
one without the other unless you are replacing the IMPL or IPL currently existing on 
your disk. (See 9.3.3 for instructions on replacing an existing IMPL and IPL.) 


To write the IMPL and IPL modules to your disk, simply omit both the ILOPT and 
IPLDK keywords from your prep job stream. The values for both of these keywords 


default to Y. The prep routine, when executed, preps your disks as an IPL volume and 
writes both the IMPL and IPL modules to your disk. 


If you do not want to prep your disk as an IPL volume, specify the keywords ILOPT=N 
and IPLDKE=N in your prep job stream. 


Disk prep for 8430, 8433, and 8494 disks does not build an IMPL file because the 5039 
and 5074 disk controllers are not loadable units. 
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System 80 Model 3 through 6 Users 


You are required to write only the IPL to your disk when prepping it as an IPL 
volume. You are not required to write the IMPL. 


To write the IPL module to your disk, simply omit the IPLDK keyword from your prep 
job stream. The value for this keyword automatically defaults to Y. When IPLDK=Y 
(specified of defaulted), the prep routine recognizes your disk as an IPL volume and 
writes the IPL module to it. 


If you do not want to prep your disk as an IPL volume, specify IPLDK=N in your prep 
job stream. 


You have the option to write the IMPL to your disk as part of the prep routine. If you 
elect to use this option, you must write both the IMPL and the IPL. You cannot write 
IMPL without also writing IPL to your disk. To write both the IMPL and the IPL, 
specify the keyword ILOPT=Y in your prep job stream and omit the keyword IPLDK 
(the value for IPLDK automatically defaults to Y). The prep routine, when executed, 
will write both the IMPL and the IPL modules to your disk. 


Considerations for Users of All Models 





Use the following device assignment when writing IMPL to your disk: 





// DVC RES 
// LBL SY$SDF 
// LFO $SY$SOF 


The number of cylinders (starting from cylinder 0) reserved for IMPL and IPL on the 
various disks supported on System 80 are as follows: 
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@ 9.3.3. Replacing an Existing IMPL and/or IPL on Your Disk (ILOPT, 
IPLDK, and RPVOL) 


You can use DSKPRP to replace either the IMPL or the IPL currently existing on your 
disk. 


To replace an existing IMPL, specify the keywords ILOPT=Y and RPVOL=Y in your 
prep job stream. You must also use the following device assignment: 


// OVC RES 
// LBL $Y$SDF 
// LFD $SY$SDF 


To replace an existing IPL on your disk, specify the keywords IPLDK=Y and 
RPVOL=Y in your prep job stream. 


In both operations, keyword RPVOL=Y allows you to make the specified replacement 
without changing any of the other information existing on your disk pack. 


Note: The canned job stream, PRPMIC, replaces both IPL and IMPL contents (see 
9.10). 


9.3.4. Recording Defective Tracks (INSRT) 


The INSRT keyword indicates to the prep routine whether INSERT control 
statements are present in your control stream. (INSERT control statements specify, 
hexadecimally, the addresses of defective areas known to exist on your disk pack. 
See 9.4 for additional information on the use of the INSERT control statement.) 


Specify INSRT=X whenever you use only INSERT control statements in your control 
stream to identify the defective areas on your disk pack. Specify INSRT=Y whenever 
you use both INSERT control statements and the normal surface analysis function to 
flag defective areas. The Y option is automatically set whenever the prep keyword 
TRCONEN is included in your control stream. 


To indicate to the prep routine that your control stream does not contain INSERT 
control statements, specify INSRT=N or simply omit it and accept the default value N 
for this keyword. 


9.3.5. Changing the Volume Serial Number (RPVOL) 


Whenever you use the RPVOL keyword, all other keywords except ILOPT, IPLDK, 
and SERNR are ignored. (These other keywords are syntax checked.) As with any 
prep operation, the VOL1 control statement must be specified. 


To change the volume serial number of a disk, use RPVOL=Y and supply the new 

volume serial number with the SERNR keyword. If you are changing the volume 

serial number in a multivolume environment, then you cannot use the VCHECK 
@ parameter in the // LBL job control statement for volume checking. 
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The volume check function checks the sequence between the volume serial number 
and the file serial number. The volume serial number and file serial number are part 
of the VTOC. The RPVOL keyword does not change the file serial number; therefore, 
in multivolume files, data management does not know the sequence of volumes being 
processed. 


ILOPT and IPLDK default to N when RPVOL=Y. 


One point of caution: If you are changing the volume serial number of a SYSRES 
volume, SYSRUN volume, or a spooling disk, be sure you don’t specify a previously 
assigned volume serial number. Such duplication may not result in a system 
duplication warning message, but it will severely impact your system. If you 
inadvertently assign a duplicate volume serial number, you must reinitialize (re-IPL) 
your entire system. 


If you want to change the volume serial number without prepping your disk, use the 
canned job control streams described in 9.10.1. 


Do not attempt to change the volume serial number and replace the IMPL or IPL at 
the same time. You must do these as separate operations. (See 9.3.3. for instructions 
on how to replace an IMPL and an IPL that currently exist on your disk.) 


To replace the user address specified for a volume, use RPVOL=Y and include the new 
user address on the VOLI card. If you do not wish to change the user address, you 
must leave that field blank on the VOL1 card. @ 





9.3.6. Specifying a Partial Prep or Building a New VOL1/VTOC (PARTL) 


When you only want to prep a portion of your disk, specify the PARTL=S keyword. 
Before you perform a partial prep, however, it is a good idea to make sure that the 
area being prepped is free of data. You do this by including the VERFY=Y keyword in 
your prep control stream (see 9.3.12). 


When you use PARTL-=S, you must use the keywords PTBEG and PTEND to indicate 
the area of the disk being prepped. TRCON=N must not be specified, since a partial 
prep does not include generating a new track/sector condition table. The testing of 
alternate tracks is automatically suppressed via the keyword ALTRK=N. You may 
specify the INSRT and PREPT keywords; however, the VTOCB, VTOCE, ILOPT, and 
IPLDK keywords are ignored if they are present in your control stream. Although 
ignored, these keywords are syntax checked. As with any prep, the keyword SERNR, 
which indicates the volume serial number, and the VOL1 card, which creates the 
standard VOL1 labels, must be specified. 


When performing a partial prep, DSKPRP destroys any and all information residing 
in the area being prepped via the PTBEG and PTEND keywords. This can be any area 
on the disk including the volume serial number and the VTOC. All areas outside the 
prep area remain unchanged. , 
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You can build a new VOL1 and VTOC without performing a surface analysis of your 
disk by using the PARTL=V keyword. You can specify this option only if your disk is 
already prepped and contains a valid VOL1. The new volume serial number specified 
by the SERNR keyword is written into the VOL1 label on the disk. In addition, all 
entries in the existing VITOC are removed and a new VTOC constructed. Removal of 
the existing VTOC entries makes your disk unusable unless you know the specific 
address of your files. This addressing could have been done by using the ADDR 
parameter in the EXT job control statement when you allocated your files. If you want 
to change your volume serial number and still have a usable disk, and you did not use 


the ADDR parameter in the // EXT job control statement, you must use the RPVOL 
keyword. 


Note: If PARTL=S is specified for the fixed-head area of an 8417 disk and 
deallocation must be performed, the prep is terminated. In this case, the entire 
disk must be prepped. 


9.3.7. Specifying the Extent (Depth) of Prep (PREPT and RETRY) 


The PREPT keyword allows you to specify the extent to which you want DSKPRP to 
conduct a surface analysis. You can choose from the following options: 


¢ PREPT=F Fast prep - read-only (minimum analysis). 
© PREPT=1 One prep pattern is written and verified. 
¢ PREPT=2 Two prep patterns are written and verified. 


e acai 3 } Three prep patterns are written and verified (most 
C in-depth analysis). 


The F option is the fastest, but least accurate, of all the preps performed by DSKPRP. 
It instructs DSKPRP to conduct only a minimum surface analysis (read-only) and 
requires the least amount of time to complete. It is useful for performing subsequent 
preps on disk packs that are factory prepped or disks that have had in-depth preps 
and are not experiencing problems during processing. 


The remaining options (1, 2, 3, and C) offer an in-depth surface analysis with option C 
or 3 being the most complete and most accurate. These options instruct DSKPRP to 
write and verify prep patterns to the disk. The more patterns written and verified, the 
more accurate the surface analysis. Of course, the more patterns you write, the more 
time it takes to perform the prep. However, if you are experiencing disk problems, 
such as unrecoverable data errors during processing, you should perform a critical 
surface analysis of that disk. 


Regardless of the type of prep you request, DSKPRP tests a given track up to the 
number of times you specified on the RETRY keyword in an attempt to have it pass 
the surface analysis test. That is, if an area is found to be defective the first time it is 
tested, it is retested up to the number of times specified by the RETRY keyword before 
it is declared bad, and an alternate track/sector is substituted for it. Thus, lowering 
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the RETRY specification has the effect of making the disk prep routine perform a 
more critical surface analysis by giving each track/sector fewer chances to pass the 
surface analysis test. Conversely, increasing the RETRY specification lowers the 
effectiveness of the surface analysis test by giving each track/sector more chances to 
pass the test. 


The number of retries is specified as a hexadecimal number from 00 to FF. The 
default number of retries is 5. 


9.3.8. Specifying Where Prepping Starts and Ends (PTBEG and PTEND) 


By omitting both the PTBEG and PTEND keywords, prepping starts at the primary 
track address of 000000 and ends at the highest primary track address of your disk. 


If you want prepping to start at some place other than the beginning of the disk and 
end some place other than the highest primary track address, you specify these 
addresses (hexadecimal) in cylinder/head format (cccchh). 


The use of PTBEG and PTEND does not prevent the initialization of the VOL1 record, 


the IMPL/IPL, or the VTOC. To suppress the initialization of these records, you must 
specify the VERFY=Y or PARTL=S parameter. 


9.3.9. Specifying Your Volume Serial Number (SERNR) 





The volume serial number is six alphanumeric characters long, which make up the 
serial number of the disk volume being prepped, and may not contain any blank 
characters. Your volume serial number may already have been assigned to the disk 
volume through a previous prep; or it may specify a new serial number. In either case, 
the SERNR keyword must always be present in your disk prep control stream. If a 
new serial number is being specified on a previously prepped disk, you should specify 
either the RPVOL keyword or the NOV option on your VOL statement. 


9.3.10. Specifying a Track Condition Table (TRCON, TRKCT, and FRMTG) 


The track condition table (TCT) or sector condition table (SCT) tells you the general 
condition of your disk and provides subsequent preps with a history of the alternate 
track/sector assignments. Figure 9-1 is a sample of a printout generated for an 8417 
disk prep. Figure 9-2 is a sample of a printout generated for an 8494 disk prep. 


The track condition table in Figure 9-1 tells you that there are three defective tracks 
(designated by a 1 in code byte 1) on the disk. The number 5 in code byte 1 for these 
tracks indicates that each defective track was not found by the surface analysis, but 
was designated by card inserts in the prep job control stream. 
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VER= 880604 Sebeseresaseeee CO/2 CISC INITIALIZATION seenenseecsenes 
CATE 88/06/10 TIME 19200323 

* CONTROL STPEAM PARAMETERS © 

SERNR=XXXKKX 


TRCON=N,INSRTZY 
vcul 


* DEFAULT PAPAMETERS # 


ALTRK=Y TLOPT=N IPLOK=Y PARTL=N PREPToF 
PTBEG=CCCOCO CTEND=CZ2ECD RETRY=CA RPVOL=N TRKCT=2 
VERFY=N VTOCB=COCANL viccr=cocano 


* INSERT PARAMFTERS # 


INSERT 004302 
INSERT €04493,GC45C6 


©S/3° TRACK CONCITION TABLE 
SERTAL NUMBEP XXXXXX 
BYTFS FIRST 


WRITTEN BAG 
ALTERNATE TRACK COTE @YTE1 CCLF PYTE2 PRIMARY TRACK CN PAC BYTE PYTE BYTE 


CYLINDER HEAC 9122 4867 C122 4567 CYLIACER ran TPeACK FCUNL FEAD EXPECTED 
C226 c9 13 §& cca? "é "oro ecco ce oa 
C326 uy 13 =¢§ urayg 23, core CocG cn on 
0226 c2 13 35 CC4sé 76 core coce cer uo 
0226 03 3 6 ccoo oo core ocec ut co 
0226 c4 2 scoc a?) £696 eoco oo ae 
0226 ce 2 ccco Cu Cua cers oc ofr 

: . C226 G6 2 cece cc cOnu "cece qr ce 
C226 u7 z ucoe iat) caeG coco co oe 
C226 ce ? coc are) "6S coca ca co 
0226 ce 2 cece a ford °tcG ao Qn 
C226 - Ga 2 ceoc cc roce coco cn oo 
0226 ce 2 % occa NG rooe c0n0 or co 
0226 cc 2 ecce OG ecoc coco cc ce 
C226 co 2 cece RS c699 Pocu cn on 
0227 ce 2 ccoo a “COG coca ce on 
9227 o1 2 occc cc FoOC csc ce tc 
C227 G2 2 cccc %G cG%S c0%0 to ac 
0227 G3 2 csce oc 76CC coco cn oc 
0227 ca 2 ccon 1c coe rece ce ithe) 
0227 Gs 2 ocso Co care oocc oc ce 
0227 C6 2 cnoc rey cooc coce cn or 
0227 c? 2 cece 2¢ “G26 Cacc or cc 
9227 ce 2 ecco °C coco CGoe oc 6° 
"227 9 ry ceoc Re 2606 eooo or ce 
9227 ca 2 ecco are) ad Shot) coca oo ae 
F227 ca 2 orce MG 30°90 cG0u oo cn 
C227 oc 2 ccoc eG "cca Faec co gc 
0227 co 2 ecco an cace cooG oc co 
C226 on 2 ecac OG coro P00 an oc 
e228 ci 2 occce aL conc cote 69 ce 
M22E a2 2 occo Ar) £oco cogs ce oc 
0226 cz 2 cece a) cuca eco ce ce 
S228 ca 2 <foe axe) fore rcoco ce ce 
S226 ts 2 occs ua?) fooG cote or ce 

i: 0226 G6 2 ccco 3b curs ecco 3n ce 
C226 C7? 2 cece cu 767 cacsa ce ec 
9228 cs 2 occe it] Lal hates occa ce ce 
0226 i 2 occo °G "aro cecc ca oe 
O22E cA 2 occe Cu Cote eocc oc oc 
C226 ce 2 cee 16 2c3c jared ere) cc un 
C228 cc 2 ores 9 5) Gc Fore 9006 ce uo 





Figure 9-1. Typical Disk Prep Printout (Part 1 of 3) 
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Figure 9-1. Typical Disk Prep Printout (Part 2 of 3) 
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C27e cs ? ites "6G "ute ccocs ce on 
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Figure 9-1. Typical Disk Prep Printout (Part 3 of 3) 


When a track is defective, an alternate track is automatically assigned. The tracks 
that are reserved as alternates are listed in the first two columns of the table. A 3 in 
code byte 1 indicates that the corresponding alternate track (designated in the first 
two columns) is to replace the corresponding defective primary track. Also, the code 
number 6 shows that the alternate track is used to store the track condition table. 


So, in this example, track 0 of cylinder 226 is assigned as an alternate to replace 
primary track 2 of cylinder 43. The alternate track for defective primary track 3 of 
cylinder 44 is track 1 of cylinder 226. And, finally, track 6 of cylinder 45 is replaced by 
the alternate track 2 of cylinder 226. 


All other tracks are listed as good (code 2) and are unassigned. 
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When prepping an 8417 disk, DSKPRP prints out a defect skip table (DST) in addition 
to a track condition table (TCT). The DST shown in part 3 of Figure 9-1, lists the 
locations of track defects. It is divided into five defect entry columns. The first half of 
each one shows the cylinder and head address of the track containing the defect. The 
second half helps you to pinpoint the defect’s location on the track and shows how 
much space was skipped to avoid the defect. The D digits indicate how far, in bits, the 
defect is from the track’s physical index marker. The L digits indicate the bit length of 
the area that was skipped to avoid the defect. 


It is important that you keep both a current diskette copy of this DST and the listing 
handy. Should serious problems occur with your disk, your Unisys representative 
needs this information to remedy any problems. 


There are two keywords associated with the processing of the TCT/SCT and, when 
prepping an 8417 disk, the DST. They are TRCON and TRKCT. TRCON instructs the 
DSKPRP routine on how to process the table(s) and TRKCT indicates where to place 
the results. 


The following options are available when you specify TRCON: 


¢ You use TRCONED to indicate the TCT/SCT is input from disk. You use this 
default option when your disk has been previously prepped (in use) and the 
current track/sector assignments are to be retained. You should always use this 
default option unless the existing TCT/SCT is unusable. 


¢ You use TRCONEN to indicate that a new TCT/SCT be generated. You must use 
this option when prepping a disk for the first time or if you cannot recover the 
existing TCT/SCT from the disk by using the TRCON=D option. The disk is 
formatted only when TRCONEN is specified. 


For 8470 disks, specify FRMTG=D also to rewrite the home address if errors are 
occurring on the high heads of the cylinders. Both TRCON=N and FRMTG=D 
must be specified to rewrite home addresses on the 8470. 


¢ You use TRCON=K when prepping an 8417 disk. It indicates that the TCT and 
the DST are input from diskette. 


When you specify TRKCT, the following options are available: 


¢ You use TRKCT=D to indicate that your TCT/SCT is written to an available 
alternate track or, for an 8494 disk, to a reserved defect cylinder. 


¢ You use TRKCT=Z to indicate that your TCT/SCT is written to an available 
alternate track or, for an 8494 disk, to a reserved defect cylinder, and listed on 
the printer. This option is the default for TRKCT. 


¢ You use TRKCT=L to indicate that your TCT/SCT is listed on the printer only. No 
other prepping functions are performed. Your disk pack must have been 
previously prepped to use this option. It is useful for future references about your 
disk pack’s track condition. 


UP-8841 Rev. 4 














DSKPRP 





¢ You use TRKCT=K only when prepping 8417 disk packs. It indicates that your 
TCT and DST are written to disk and diskette and also listed on the printer. It is 
recommended that you use this option for backing up your DST. 


¢ You use TRKCT=B only for 8417 disk packs. It indicates that your TCT and DST 
are written only to diskette and listed on the printer. No other prepping functions 
are performed. This option is useful when you want to back up your DST without 
prepping your disk pack. You can only use this option if your disk pack has been 
previously prepped. 


Notes: 


1. All TRKCT options that update the TCT also write the TCT to an available 
alternate track so subsequent preps may use previous surface analysis results and 
INSERT specifications. 


2. Processing the DST on a diskette requires a device assignment for the diskette. The 
LFD name required in the device assignment set is | / LFD DSKET. 


The alternate assignment table that is printed for the 8494 disk is called the sector 
condition table (SCT) (see Figure 9-2). The SCT is maintained on a cylinder that is 
reserved for storing defect information. There are significant differences between the 
SCT format and the TCT format. 


OS/3 SECTOR CONDITION TABLE 
SERIAL NUMBER UNISYS 
PHYSICAL DEFECTIVE PHYSICAL DEFECTIVE LOGICAL 


ALTERNATE ADDRESS CODE BYTE PRIMARY ADDRESS PRIMARY ADDRESS 
cylinder head sector 0123 4567 cylinder head sector cylinder head sector 


@@5A e9 20 123 @Q5A 05 2B Q02E GE 17 
@ODF 00 14 123 @@DF 84 OF 6073 @3 3F 
O1F2 69 2D o1 4 

O1F2 e9 2E 12 O1F2 @5 08 0101 61 61 
0494 69 20 123 0494 06 1c @25C @D o9 


CODE BYTE DEFINITION: 
BIT @ - SECTOR IS DEFECTIVE 
BIT 1 - SECTOR IS AN ALTERNATE 
BIT 2 - ALTERNATE SECTOR IS ASSIGNED 
BIT 3 - DEFECTIVE ENTRY FOUND BY THE FACTORY 
BIT 4 - SECTOR I1.D. IS DISPLACED 
BIT 5 - SECTOR I.D. IS EXTENDED DISPLACED 


Figure 9-2. Sample Sector Condition Table 


UP-8841 Rev. 4 | 9.15 


DSKPRP 








9.3.11. 


9-16 





The PHYSICAL ALTERNATE ADDRESS indicates the address of the alternate 
sector. The CODE BYTE provides information about the alternate sector. The 
DEFECTIVE PHYSICAL PRIMARY ADDRESS indicates the physical address 
(assuming fifty 512-byte sectors per track and 10 tracks per cylinder) of the 
defective sector. The DEFECTIVE LOGICAL PRIMARY ADDRESS indicates the 
logical address (assuming ninety-six 256-byte records and 20 tracks per cylinder) 
of the defective sector. The record number represents an odd/even pair of 256- 
byte records. OS/3 uses these logical addresses to access the disk. If an alternate 
sector is defective, there are no defective physical or logical primary address 
entries. 


The sample SCT shown in Figure 9-2 has five alternate sector entries. One of the 
alternates is defective with a displaced I.D. field (01F2/09/2D). The other four 
alternates are assigned to defective primary sectors. 


Specifying the VTOC Address (VTOCB and VTOCE) 


The VTOC is a directory that contains the addresses of the files contained in your 
volume. You can indicate where you want the VTOC to reside by specifying six 
hexadecimal numbers representing the starting primary track address in 
cylinder/head format (cccchh) on the VTOCB keyword. The starting address must be 
less than the end VTOC address and must be at least one track in length; however, we 
recommend that one cylinder be allocated for the VTOC. By omitting the VTOCB 
keyword, DSKPRP automatically assigns the starting VTOC address for you. 

Table 9-1 lists the default VTOC starting addresses for both IPL and non-IPL disk 
volumes. 





Table 9-1. Default Starting VTOC Addresses for Disk 





After you have indicated the starting address of your VTOC, the next step is 
specifying the ending address. You can specify the hexadecimal numbers to indicate 
the cylinder and head address of the ending track on the VTOCE keyword. By 
omitting the VTOCE keyword, DSKPRP automatically assigns the ending VTOC 
address for you. Table 9-2 lists the VTOC ending addresses for both IPL and non-IPL 
disk volumes. , 
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Table 9-2. Default Ending VTOC Addresses for Disk 





Notes: 
1. The VIOC cannot be placed in the fixed-head area of an 8417 disk. 


2. The number of cylinders (starting from cylinder 0) reserved for IMPL and IPL on the various disks supported 
on System 80 are as follows: 


Disk Type 





9.3.12. Testing an Area before Prepping (VERFY) 


If you're doing a partial prep, it’s a good idea to test the area to be prepped first to 
make certain that that area is free of data. You use the VERFY=Y keyword to do this 
testing. Whenever you specify VERFY=Y, the keywords PTBEG, PTEND, and SERNR 
must also be specified. In addition, TRCON cannot be an N. The keyword ALTRK=N 
is assumed while the keywords VTOCB, VTOCE, ILOPT, and IPLDK are ignored if 
they’re present in your control stream. They are, however, syntax checked. The INSRT 


and PREPT keywords may be used, if needed. As with all preps, the VOL1 card must 
be specified. 


By specifying VERFY=N or omitting the keyword, no testing is performed. 


Note: If the area defined by the PTBEG and PTEND keywords is occupied, the prep 


will automatically stop, and no action will take place. Also, the VOL1 label or 
the VTOC area is not rebuilt. 
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9.3.13. Checking the File Expiration Date (UNXFC) 


You use the UNXFC=Y keyword to check the expiration date for all files on your 
volume. When you use this keyword, you prevent any file from being scratched if the 
expiration date has not expired. 


DSKPRP compares the system date to the expiration date for each file. Whenever the 
expiration date is greater than the system date, a message is displayed indicating the 
expiration date has not expired (up to 10 files at a time can be displayed). Associated 
with this message, DSKPRP gives you the option to ignore the message and continue 
with the prep or cancel the prep. Normally, you would cancel the prep when the 
expiration date has not expired. 


If you omit the UNXFC keyword or specify UNXFC=N, no expiration date validation 
is performed. 


9.4. Assigning Alternates for Suspected Defective 
Tracks/Sectors (INSERT) 


The INSERT control statement is used to identify any known defective tracks/sectors. 
Any tracks/sectors that you specify on INSERT control statements are assigned 
alternates. 





You must identify the tracks/sectors on INSERT control statements by their 
hexadecimal equivalents. You can either specify one track/sector on each INSERT 
control statement or use one INSERT control statement to specify a number of 
tracks/sectors, as long as the list of entries does not extend beyond column 71. 
Whenever INSERT control statements are present in your control stream, you must 
specify either keyword INSRT=X or keyword INSRT=Y. 


A list of any known defective tracks is supplied by the manufacturer for your 
removable disk packs. This list appears on a label located on the bottom of the plastic 
cover for your disk pack. The label also lists your pack’s volume serial number. The 
defective tracks are listed both decimally and hexadecimally in cylinder and head 
format (cccchh). Defective tracks for your 8417 nonremovable disks are found in the 
OS/3 track condition table in the disk prep printed for that pack. (The 8417 disk packs 
go through an extensive surface analysis during the manufacturing process.) 


The format of the INSERT control statement is 


1 18 


INSERT ecechh[,cecchh...,ccecchh] 
ecechhrr[, cecchhrr...,cecchhrr) (8494 only) 
NONE 
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where: 


ecechh 
Is the hexadecimal address in cylinder/head format of a possible defective 
track to be flagged . 


ecechhrr 
Is the hexadecimal address in cylinder/head/record format of a possible 
defective record to be flagged. This format applies to 8494 disks only. 


NONE 
Indicates that there are no known defective tracks. 





9.5. Creating Standard Volume Labels (VOL1) 


. The VOL1 label is the standard volume label in OS/3. It’s used to identify your volume 
by a unique serial number and is also used to locate the address of the VTOC. You 
must specify a VOL1 statement every time you do a prep. 


The format of the VOL1 statement is 


1 11 42 51 


@ VOL1 tr] [aaaaaaaaaal 


When coding the VOL1 statement, VOL1 must start in column 1. Column 11 is 
reserved for future use to specify a security byte (r). Columns 42 through 51 are used 
for a name or address of the disk. Normally, the contents of this field is up to the user. 
Figure 9-3 shows the format of a VOL1 label as it appears on a disk. 


The VOL1 label is identified by the word VOL1 in the label identification field, which 


is the first field in the label. The VOL1 label for disk is always written on cylinder 0, 
head 0, record 3. 
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LABEL IDENTIFIER LABEL NUMBER 


VOLUME SERIAL NUMBER 







12 
VOLUME SECURITY 







16 
VOLUME TABLE OF CONTENTS ADDRESS 





24 


OWNER NAME AND ADDRESS CODE 








RESERVED 





Figure 9-3. VOL1 Format 
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® 9.6. Prepping Your Diskette 


The same routine for prepping disks (DSKPRP) is also used for prepping diskettes. 
However, because of certain hardware design differences, the prepping options for 
diskettes are different from that for disks. When prepping your diskette, you can 

e Analyze the surface for defective tracks. 

e Change your diskette volume serial number. 

¢ Indicate whether your diskette is to be used as an IPL volume or not. 

© Indicate whether your diskette is to be used as an IMPL volume or not. 

© Replace either the IPL or IMPL (but not both). 


¢ Format your diskettes in either data set label (DSL) mode or format label (FLB) 
mode. 


© Indicate where you want the volume table of contents (VTOC) to reside on a 
format label diskette. 


e Build anew VOLI and VTOC or DSLs without performing a surface analysis. 

@ For diskette preps, the DSKPRP options associated with assigning alternate tracks 
may not be used. Instead, each diskette already contains two tracks reserved as 
alternate tracks. No alternate tracks can be assigned by the user. If more than two 
defective tracks are found on a diskette, the diskette must be discarded. 


The DSKPRP options associated with partial prepping may not be used with 
diskettes. 
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9.7. Specifying Prep Options for a Diskette 


Just as when you prep a disk (see 9.3), you choose the prep options for a diskette by 
selecting one or more of the following keywords. The formats of the keywords are 


Y 


,FORMT= (PI ,FDATA= {*} ;DNSTY= {*} ,;RECSZ= ( {2H 
ar N 2 256 
512 


fae {3} SERNR=voLUne-ser fal -runber 


eas ecechh 
{cazies (for 8420/8422 IPL and non-IPL volumes) 





ae fH) 


, IMPNM= , nnnn 
(for model 3-6 systems) 
J (for model 8-20 systems) 





1DC 
IOMP 
DBUS 
FDD@ (for model 8 systems) 


oy eccchh 
{eva (for 8420/8422 IPL and non-IPL mess 
t, 


CUADR=nnn] 


Notes: 
I. The SERNR keyword must be specified every time you prep a diskette. 


2. There is no option to specify single-sided or double-sided diskette. These are 
physical characteristics of a diskette. 
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9.7.1. Changing the Diskette Volume Serial Number or Replacing the IMPL 
or IPL (RPVOL) 


To change the diskette volume serial number, use RPVOL=Y and supply the new 
volume serial number with the SERNR keyword. 


To replace the existing IMPL or IPL without destroying the existing information on 
your diskette, use ILOPT=Y or IPLDK=Y with RPVOL=Y. You cannot change a 
volume serial number and replace IMPL or IPL at the same time. Whenever you use 
the RPVOL keyword, all other keywords except ILOPT, IPLDK, and SERNR are 
ignored. However, these keywords are syntax checked. As with any prep operation, 
the VOL1 control statement must be specified. 


To change the volume serial number without prepping the diskette, use the canned job 
control stream called CHGVSN (see 9.10.1). 


Note: Replacing the IMPL requires the following device assignment: 
// DVC RES 


// LBL $YSSDF 
// LED SY$SDF 


@ 9.7.2. Specifying the Diskette Volume Serial Number (SERNR) 
The volume serial number is six alphanumeric characters that make up the serial 
number of the diskette being prepped. It may not contain any blank characters. Your 
volume serial number may already have been assigned to the diskette through a 
previous prep or it may specify a new serial number. In either case, the SERNR 
keyword must always be present in your prep control stream. 
If SERNR is the only keyword used, the prep will automatically perform the following: 
1. Reinitialize the data set labels. 
2. Change the volume serial number to the value of SERNR. 
3. Write a prep pattern and analyze all data records of the diskette, ensuring their 

availability. 


9.7.3. Indicating Diskette Format (FORMT) 


A diskette can be prepped in either data set label (DSL) mode, to simulate a 
sequential file like a tape file, or in format label (FLB) mode, to simulate a disk file. 
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You specify your choice with the FORMT keyword, as follows: 


e DSL indicates that the format is in data set label mode. Your diskette will 
contain records with either 128-, 256-, or 512-byte record sizes, written in single 
or double density. You cannot, however, specify a record size of 128 bytes when 
prepping a double-density diskette. 


¢  FLB indicates that the format is to be in format label mode. Your diskette is 
limited to a 256-byte, double-density, two-sided surface. A VTOC is generated 
and a disk-like VOL1 label is written on sector 3 of the index track. 


A VOLI statement is always needed, no matter what format is specified. 





9.7.4. Specifying File Allocation for DSL Diskettes (FDATA) 


The disk prep routine automatically allocates the entire diskette (FDATA=Y) as being 
one file and names that file DATA. Therefore, if you are using the diskette as a work 
file, there is no need to allocate file space (using the // EXT statement). However, if 
you later decide to use the diskette in a multifile environment or use a different name, 
you must scratch the file before allocating a new one. You can scratch files using either 
the PARTL=V keyword (see 9.7.13) or via the SCR job control statement. 


You can also specify the diskette to be made available for any file allocation (just as a 
disk) by specifying FDATA=N. (When FDATA&N, the file DATA is not built.) Once 
prepped, you then allocate the required file space using the // EXT job control 
statement with the BLK parameter or the interactive services ALLOCATE command. 





Notes: 


1. You can also scratch files interactively via the interactive services ERASE 
command. See the current version of the Interactive Services Operating Guide 
(UP-9972) for details. 


2. The FDATA parameter is not applicable with format label diskettes. 


9.7.5. Specifying Diskette Density (DNSTY) 


When specifying the density at which the diskette is prepped, you must use the 
keyword DNSTY=n, where 7 is either 1 for single density or 2 for double density. 


9.7.6. Specifying Record Size (RECSZ) 


The size of the record to be created on the diskette is specified by the keyword 
RECSZ=nnn, where nnn is the size of the record. Possible values for this keyword are 
128, 256, and 512 bytes. The default parameter is 128 bytes for the DSL mode. 
However, you cannot specify a record size of 512 bytes when writing IMPL or IPL to 
the diskette. 
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When prepping a double-density FLB diskette, you can only specify a record size of 
256 bytes. 


9.7.7. Spiraling Records to Reduce Track-to-Track Latency Time (SPIRL) 


You can minimize track-to-track latency time by specifying the keyword SPIRL=Y. 
When this keyword is specified, a predetermined number of physical records are 
skipped when numbering logical records from track to track. This causes the first 
logical record of each track to appear to spiral in relation to its physical index marker. 
Therefore, when the read/write head moves from one track to another, the surface 
rotates the first logical record under the head without the loss of a revolution. As a 
result, the time needed to access records from track to track is reduced. 


9.7.8. Lacing Records to Reduce Latency Time within a Track (LACEG) 


You can minimize the latency time within the track itself by specifying the 
LACEG=nn keyword, where nn is the number of physical records on a track that are 
offset between logical records. You can specify a decimal number from 01 through 25, 
with the default being 01. 


When you use the LACEG keyword, each logical record on a track is separated by the 
number of physical records you specify. By lacing your records properly, you can space 

& your records on the track so that each logical record is rotated under the read/write 
head just as the I/O order to retrieve it is issued. As a result, you can access a number 
of records without the loss of a revolution. 


9.7.9. Loading Initial Microprogram Load to Diskette (ILOPT) 

You write initial microprogram load (IMPL) to diskette by specifying ILOPT=Y. The 
default for the keyword is ILOPT=N. The following device assignment set is used for 
your disk-resident volume when writing IMPL to diskette: 

// DVC RES 

// LBL $Y$SDF 

// LED $YSSDF 
You may also use the ILOPT keyword to replace IMPL on your diskette. When 
replacing IMPL, ILOPT=Y must be specified along with RPVOL=Y and the SERNR 
keyword. 
Notes: 
1. Both IPL and IMPL cannot be loaded to the same diskette. 


2. RECSZ cannot have a value of 512 bytes. RECSZ must be 128 bytes if 
IMPNM=FDD0. The diskette must be single sided and SERNR=S$IMPL. 
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3. CUADR must be specified on model 8 systems unless IMPNM=FDDO. 





4. See 9.7.14 and 9.7.15 for additional information concerning IMPL loading. 


Indicating Your Diskette Is an IPL Volume (IPLDK) 

The IPLDK keyword indicates whether the diskette being prepped is used as an IPL 
volume or not. If the IPLDK=Y option is specified, the diskette is indicated as an IPL 
volume. If the diskette is not to be used as an IPL volume, the IPLDK=N option must 
be specified or omitted. You replace IPL by specifying IPLDK=Y along with RPVOL=Y 
and the SERNR keyword. The default is IPLDK=N. 

Notes: 

1. Both IPL and IMPL cannot be loaded to the same diskette. 


2. RECSZ cannot have a value of 512 bytes. 


Checking the File Expiration Data (UNXFC) 


You use the UNXFC keyword to check the expiration date for all files on your volume. 
When you use this keyword, you prevent any file from being scratched if the 
expiration date has not expired. © 





DSKPRP compares the system date to the expiration date for each file. Whenever the 
expiration date is greater than the system date, a message is displayed indicating the 
expiration date has not expired (up to 10 files at a time can be displayed). Associated 
with this message, DSKPRP gives you the option to ignore the message and continue 
with the prep or cancel the prep. Normally, you would cancel the prep when the 
expiration date has not expired. 


If you omit UNXFC keyword, no expiration date validation is performed. 


Specifying the VTOC Address (VTOCB and VTOCE) 


The VTOC is a directory that contains the addresses of your program library files that 
are contained in your volume. If you specified the FORMT=FLB keyword in your job 
control stream, you can indicate where you want the VTOC to reside by specifying six 
hexadecimal numbers representing the starting primary track address in cylinder/ 
head format (cccchh) on the VTOCB keyword. The starting address must be less than 
the end VTOC address and must be at least one track in length; however, we 
recommend that one cylinder be allocated for the VTOC. By omitting the VTOCB 
keyword, DSKPRP automatically assigns the starting VTOC address for you. 


Table 9-3 shows the default VTOC starting addresses for both IPL and non-IPL 
diskette volumes. 
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Table 9-3. Default Starting VTOC Addresses for Diskette 





8420/8422 


After you have indicated the starting address of your VTOC, the next step is 
specifying the ending address. You can specify the hexadecimal numbers to indicate 
the cylinder and head address of the ending track on the VTOCE keyword. By 
omitting the VTOCE keyword, DSKPRP automatically assigns the ending VTOC 
address for you. 


Table 9-4 shows the VTOC ending addresses for both IPL and non-IPL diskette 
volumes. 


Table 9-4. Default Ending VTOC Addresses for Diskette 






IPL Volume 


8420/8422 
Note: The VTOC cannot be written on cylinder 0, head 0. 


Building a New VOL1 and VTOC or DSLs (PARTL) 


To speed up your prep (since no surface analysis is performed), you specify the 
PARTL=V keyword. Not only does it run faster, it is also an easy and quick method of 
scratching unwanted files (rather than using job control). You can only use PARTL=V 
on a prepped diskette. 


You can also specify a new volume serial number through the PARTL=V keyword. The 
volume serial number indicated on the SERNR keyword is written in the VOL1 
label(s). This keyword removes all the entries from the VTOC or DSLs, thus making 
the diskette unusable unless you know the specific address of your files. If you know 
the specific address, you use the ADDR parameter on the EXT job control statement 
during file allocation (format label only). 


Whenever you use the PARTL=V keyword, the RECSZ and DNSTY keyword values 
must be the same as you specified for your original prep. In other words, if you 
specified RESCZ=256 and DNSTY=2, you cannot change the keyword values in the 
same control stream with the PARTL=V keyword. If you want to change the RECSZ or 
DNSTY values, omit the PARTL keyword or use PARTL=N. 
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9.7.14. Specifying the IMPL Module Type Written to Diskette (IMPNM) $ 


There are six IMPL module types that you can write to diskette: CPU, IDC, IOMP, 
DBUS, IDCU, and FDDO. The first five (CPU, IDC, IOMP, DBUS and IDCU) are 
supported on models 3 through 6 with CPU as the default module type on these 
models. Module types IDCU and FDD0 are the only types supported on model 8 with 
IDCU as the default type. Only IDCU is supported on models 10/15/20. 


When you specify IMPNM, you must also specify the parameter ILOPT=Y and the 
device assignment set for the $Y$SDF file. The $Y$SDF file must contain the name of 
the microcode. This name is entered via the system defintion utility (SDU) product. 
The actual microcode load module resides in $Y$MIC. The prep routine searches 
$Y$SDF for the microcode name associated with the module type specified by 
IMPNM. The microcode is then loaded from $Y$MIC and written to the diskette. See 
the Installation Guide (UP-8839) for a description of the IMPLDSKT job stream. 


If you are a model 8 only (not models 10/15/20) user, you are supplied with a diskette 
containing the FDDO microcode. To back up your FDD0 diskette or to create an 
updated FDD0 diskette (via an SMC), you must specify the following options: 
IMPNM=FDD0, ILOPT=Y, and SERNR=S$IMPL. The FDDO IMPL diskette must be 
single sided with a record size of 128 bytes and must not contain any defective tracks. 
If a bad track is found, the diskette prep is terminated with errors. Another diskette is 
then needed. (Attempting to specify IMPNM=FDD0 on a model 3 through 6 system 
results in error.) (See the Installation Guide (UP-8839) for a description of the 
FDDODSKT jobstream that allows you to create a FDDO IMPL diskette.) To back up 
your FDD0 diskette on the models 10/15/20, see the Installation Guide (UP-8839) for a 
description of the FDDCOPY jobstream. 





9.7.15. Specifying the Control Unit Address for Model 8 through 20 IMPL 
(CUADR) 


This parameter is applicable only to model 8 through 20 users. It allows you to write 
the IMPL (IDCU) that supports the control units onto a diskette. It is required 
whenever you specify the ILOPT=Y and IMPNM=IDCU parameters. The value you 
specify for CUADR must be the control unit address of the IDCU disk(s) and must be 
device number 0 on the control unit (e.g., 390, 3A0, 280, etc.). The CUADR parameter 
is not needed if IMPNM=FDD0. It is ignored if specified on model 3 through 6 systems 
except for syntax checking. 


9.8. Initializing the Data Set Labels 


The data set labels written on track 00 of your diskette are similar to the VTOC of a 
disk. The data set labels are reserved for defining the name of a set of files and the 
addresses associated with the maximum space the set of files can occupy. You must 
specify a VOL1 statement every time you do a prep. 
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The format of the VOL1 statement is 
1 42 55 
VOL 1 [aaaaaaaaaaaaaa) 


The VOL1 statement must start in column 1. Columns 42 through 55 are used for a 
name or address of the diskette. The contents of this optional field is up to the user. 


9.9. Executing the Disk Prep (DSKPRP) 


When executing DSKPRP to prep any kind of disk or diskette, there are two file 
names that must always be specified on the // LFD job statements. The file name for 
the printer must be PRNTR, while the file name of your disk or diskette must be 
DISKIN. If a track condition table (TCT) and a defect skip table (DST) are wanted as 
input and/or output to a diskette, the file name, DSKET, must be supplied on the // 
LFD job statement in the diskette device assignment set. No minimum or maximum 
main storage sizes should be specified on the // JOB card, as the minimum amount of 
main storage needed by DSKPRP is automatically allocated for the job by job control, 
and providing any more than the minimum only wastes valuable main storage space. 
DSKPRP is not a program that uses main storage dynamically. 





The following control streams show some typical DSKPRP examples: 


@ Example 1: Disk 8470 Prep in which Defective Tracks Are Assigned Alternates 


1 18 16 





1. | // JOB PREP8470 

2. | // DVC 20 // LFD PRNTR 

3. | // DVC 5@ // VOL DS847@(NOV) // LFD DISKIN 
4. | // DVC RES // LBL $YSSDF // LFD SY$SDF 
5. | // EXEC DSKPRP 

6. | /$ 

7. SERNR=DS847@, TRCONEN, 

8. | VOL1 

9. | INSERT 002002, 007008,011101 

10.| /* 

11.] /& 

12.| // FIN 


1. Line 1 is the job control statement identifying your job as PREP8470. 

2. Next, enter the required file name for the printer, PRNTR. 

3. Online 3, you specify the device assignment set for the disk to be prepped. 
According to this assignment set, your disk is on device number 50, the 


volume serial number is DS8470, and you are using the NOV option 
@ indicating that no check is required for the volume serial number. The file 
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name DISKIN must be specified on the // LFD job control statement, since 
this is the required file name for the disk. 


The device assignment set in line 4 is required only if your prep is being 
conducted on a model 8 through 20 system because the parameters used to 
write the IPL and IMPL to disk default to yes (Y) are IPLDK=Y and 
ILOPT=Y. 


The EXEC control statement calls the disk prep routine (DSKPRP) from 
$Y$LOD. 


The /$ job control statement indicates the start of the prep data. All your 
prep keywords or control statements must follow this statement. 


On line 7, you specify the volume serial number (DS8470) and indicate that a 
new TCT is to be generated. 


The VOL1 statement must appear in disk prep control streams and always 
follows the last specified keyword. The only exception is when you are using 
the assign alternate track (AAT) feature of the disk prep routine. 


The INSERT control statement flags the following addresses as defective: 
002002, 007008, 011101. 


10. through 12. 


The /*, /&, and // FIN job control statements terminate your job. 


Since no special prep is specified, it defaults to fast prep (PREPT=F). The VTOC 
is placed on cylinder CA and the TCT is written to an alternate track and printed. 


Example 2: Disk 8417 Prep in which the TCT/DST Is Input and Output to a Data Set Label 


On Our WD a= 
. © © «© @ «8 «@ @ 


Diskette 
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// JOB PREP2 

// DVC 20 // LFD PRNTR 

// OVC 5@,108 // VOL WORK(NOV) // LFD DISKIN 

// DVC 138 // VOL D@8420 // LBL DATA // LFD DSKET 
// EXEC DSKPRP 


/$ 
SERNR=WORKDC 
TRCON=K 
TRKCT=K 
PREPT=1 
TPLDK=N 

VOL 1 

INSERT NONE 

* 

/& 

// FIN 
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1. Line 1 isthe job control statement identifying your job as PREP2. 

2. The device assignment set for the printer is shown in line 2. 

3. You specify the device assignment set for the disk being prepped. According 
to this assignment, your disk is mounted on the disk drive with the 
hardware address 100, the VSN is WORK, and you are using the NOV 
option. The required file name for this assignment set is DISKIN. 

4. Line 4 contains the device assignment set for the diskette that is used as the 
input and output for the TCT/DST. The required file name for the diskette is 
always DSKET. 

5. The EXEC job control statement that calls the disk prep routine. 

6. Enter the job control statement (/$). 

7. Line 7 specifies the volume serial number as WORKDC. 

8. Line 8 specifies that the input of the TCT/DST is from diskette. 

9. Online 9, the entry specifies that the output of the updated tables is to 
diskette, disk, and the printer. 

10. and 11. 

Indicate that only one prep pattern is used (PREPT=1) and that the disk is 
not to contain the IPL code. 

12. and 13. 


Contain the VOL1 statement and INSERT NONE (0 INSERT tracks). 


Example 3: Disk 8419 Prep in which IMPL/IPL Is Written to Disk 
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// JOB PREPIMPL 
// DVC 20 // LFD PRNTR 
// OVC RES 
// LBL $Y$SDF 
// LED SYSSOF 
// DVC 5@ // VOL BACKUP // LFD DISKIN 
// EXEC DSKPRP 
1% 
SERNR=BACKUP 
ILOPT=Y 
IPLDK=Y 


-{ VOL1 


INSERT NONE 


-| /* 
| /& 


// FIN 
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1. The job control statement identifying your job as PREPIMPL. 

2. The device assignment set for the printer. 

3. through 5. 
These lines specify the device assignment set for your disk-resident volume. 
This device assignment set must be specified whenever you are writing 
IMPL to disk. 

6. The device assignment set for the disk being prepped. 

7. Line 7 contains the EXEC job control statement that calls the disk prep 
routine. 

8. The job control statement (/$) indicates the start of prep data. 

9. Line 9 specifies the volume serial number as BACKUP for the disk being 
prepped. 

10. The ILOPT keyword specifies that IMPL is written to disk. 

11. Because IPL must also be written when writing IMPL to disk, IPLDK=Y is 
specified. 

12. Enter the VOL1 statement on line 12. 

13. Since there are no INSERT tracks, INSERT NONE is specified. 


Example 4: Diskette Prep in the DSL Mode 





// JOB PREP&42@ 

// DVC 20 // LFD PRNTR 

// DVC 138,328 // VOL D@7@98(NOV) // LFD DISKIN 
// EXEC DSKPRP 

/$ 


SERNR=D07898 

RECSZ=256 

DNSTY=2, LACEG=03, FDATA=N 
VOL 1 
/* 


-| /& 


// FIN 


The job control statement identifying your job as PREP8420. 


The file name for the printer. 
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3. In line 3, you specify the device assignment set for the diskette to be 
prepped. According to this assignment set, your diskette is mounted on the 
device with the hardware address 320, your volume serial number is 
D07098, and you are using the NOV option indicating that no check is 
required for the volume serial number. The file name DISKIN must be 
specified on the // LFD job control statement because this is the required file 
name for the diskette. 


4. The EXEC job control statement calls the disk prep routine (DSKPRP) from 
$Y$LOD. 


5. The/$ job control statement indicates the start of the prep data. All your 
prep keywords and control statements must immediately follow the /$ job 
control statement. 


6. In line 6, you specify the volume serial number (D07098). 


7. Inline 7, you specify a record size of 256 bytes and the diskette format 
defaults to data set label. 


8. In line 8, the density is specified as 2 and the lacing factor as 3. FDATA=N 
indicates that the file DATA will not be allocated. 


Figure 9-4 shows ‘he printout generated by this control stream. (Although 
the printout lists a default value for the RETRY parameter, this parameter 
is not supported when DSKPRP is used for diskettes.) 





VER 880317 kekkekeeeieee == 05/3 DISC INITIALIZATION  *#8ktkkeReRRR 
DATE 88/04/26 TIME 12:01:09 

* CONTROL STREAM PARAMETERS * 

SERNR=007098 


RECSZ=256 

DNSTY=2, LACEG=03, IPLDK=N, FDATA=N 

VOL 

* DEFAULT PARAMETERS * 
PARTL=N RETRY=0A RPVOL=N VTOCB=002400 VTOCE=002401 
SPIRL=N UNXFC=N FORMT=DSL_ — ILOPT=N 


USAJU NORMAL EOJ + DISKETTE IS GOOD 


UNISYS SYSTEM OS/3 DISC INITIALIZATION COMPLETE 
DATE- 88/84/26 TIME- 12:02:58 UPSI- X'0' 
VSN- 0067098 TYPE- 8420 


LEER Snennaneaanat 


Figure 9-4. Printed Ouput for DSL Diskette Prep 
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Example 5: Basic 8420 Diskette Prep 





// JOB D13PREP 
// DVC 20 // LFD PRNTR 
// DVC 138 // VOL DS8420(NOV) // LFD DISKIN 


SERNR=DS8420 
VOL 1 


When executing the basic 8420 diskette prep, the only keyword required is 
SERNR, indicating your volume serial number (DS8420). The diskette is prepped 
in data set label mode, single density, with a record size of 128 bytes. 

Example 6: Changing the Volume Serial Number without Prepping 
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// JOB D13CHNG 

// DVC 20 // LFD PRNIR 

// DVC 13@ // VOL DS8420(NOV) // LFD DISKIN 
// EXEC DSKPRP 

/$ 





SERNR=DUMMY 1, RPVOL=Y 
VOL1 


In this example, you are changing the volume serial number from DS8420 to 
DUMMY! while leaving the rest of the diskette unchanged. 
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Example 7: Replacing the CPU IMPL Module on an 8420 Diskette in a Model 3 through 6 
Environment 
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1. | // JOB DSKTIMPL 

2. | // DVC // LFD PRNTR 
3. | // DVC RES 

4. | // LBL $Y$SDF 

5. | // LFD SYSSDF 

6. | // DVC 130 // VOL IMPL@1(NOV) // LFD DISKIN 
7. | // EXEC DSKPRP 

8. | /$ 

9. SERNR=IMPLO1 
10. RPVOL=Y 

11. 1LOPT=Y 

12.] VOL1 

13.| /* 

14.] /& 

15.| // FIN 


In this example, you are replacing the CPU IMPL initial microprogram load 
module on your diskette. The job control statements shown in lines 3, 4, and 5 
compose the device assignment set for your disk-resident volume. Include them in 
your job control stream when writing IMPL to a diskette. 

Line 6 contains the device assignment set for the diskette being prepped. 

The keywords listed in lines 9 through 11 replace the IMPL module CPU on your 


diskette (IMPNM defaults to the value CPU on models 3 through 6). The 
ILOPT=Y keyword specifies that IMPL is written to diskette. 


9.10. Prep Canned Job Control Streams 
The following canned job control streams provide you with a more convenient method 
of performing certain prep functions without specifying the parameters and job control 
statements normally required to run them. They are 
¢ CGV/CHGVSN - Changes the volume serial number on a prepped disk. 
¢ SETREL - Preps and allocates RELEASE/SYSRES files. 
¢ COPYREL - Copies selected system files. 
¢ IMPLDSKT - Creates microcode diskette. 


¢ FDDODSKT - Creates system microcode diskette for model 8. 
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¢ FDDCOPY - Creates system microcode diskette for models 10/15/20. 


e PRPMIC - Rewrites current IPL/IMPL module on disk. 


These functions are initiated from the system console by keying in their associated job 
control stream names. 


The CGV/CHGVSN, SETREL, and COPYREL functions are described in this section. 
See the Installation Guide (UP-8839) for descriptions of the other job control streams. 


Change a Volume Serial Number (CHGVSN/CGV) 


The CHGVSN/CGV system utility routine changes the volume serial number (VSN) on 
a previously prepped disk or diskette. The new VSN replaces the old one in the VOL1 
record. The required parameters are supplied either on cards in the card reader or as 
operands with a command keyed in at the system console. 


Note: Extreme care should be used if changing the VSN of a SYSRUN, a SYSRES, or 
a spooling disk. Specification of a duplicate VSN may not cause a duplication 
error message to be issued, but will severely impact the system. If a duplicate 
VSN is inadvertently assigned, the entire system must be reinitialized (IPL). 

Card Input Keyin (CHGVSN) 


When the parameters are input via cards in the card reader, the following command is 
keyed in at the system console: 


RU CHGVSN 
In addition, the following cards must be in the card reader: 
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//OLDVSN JSET ‘old-vsn! 
//NEWVSN JSET 'new-vsn! 
J/TYPE JSET 'disk-type' 
// FIN 


where: 


‘old-vsn' 
Specifies the old volume serial number of the previously prepped disk. 


'new-vsn' 


Specifies the new volume serial number to be assigned to the prepped disk. 
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Note: For cardless systems, RU CHGVSN will read parameters from diskette. 


System Console Keyin (CGV) 


'disk- type! 


Specifies the type of disk subsystem being used. The values may be: 


Disk Type 


Value 


8416 
8417 
8418 
8419 
8420 
8422 
8430 
8433 
8470 
8494 


DSKPRP 


When the parameters are entered as operands with a command keyed in at the 


system console, the command has the following format: 


RV CGV, ,O=old-vsn,N=new-vsn, T=disk- type 


Keyword Parameters 


O=old-vsn 


Specifies the old volume serial number of the previously prepped disk. 


N=new-vsn 


Specifies the new volume serial number to be assigned to the prepped disk. 


T=disk- type 


Specifies the type of disk subsystem being used. The values may be 
Disk Type 


Value 


8416 
8417 
8418 
8419 
8430 
8433 
8470 
8494 


After you enter the RV CGV command, the CGV job executes the DSKPRP routine to 
change your volume serial number. When the DSKPRP routine has completed, you 


receive a printed listing like the one in Figure 9-5. 
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8E6 


4/ $08 CGV U3s325S8 
41 NOP 498866 RSs $8 66E4 98 FO OESS O48 FSSSEEFEEEEEEEESEEEESSTESEEEEESES EES 12232353 
47° NOP ®& 21332356 
S17 NOP C8 Oe He aes 62 FS OSEESHHSHEEEESESECERERSESESESESSSEEOESSESESESESEESES 82:32:58 
4/ NOP 11232334 
4/7 NOP © 182322540 
47 NOP © 12332758 
47 NOP & 12232354 
4/ NOP tis32sSe 


V1s32:846 
1hs32386 
02:32:55 


4/7 GBL O,N,T 
4/7 ALTUCS SGSUCS 
4/ OPTION SCAN,SUB 


// wRTSIG * poo419 Tor,® RELUSO* 21:32:58 
47 OVC 29 11:32:59 
4/ LFO PRNTR 41332359 
4/7 NOP 21:32:59 


11232359 
31:33:01 
11333302 
11:33:02 


4/450 OSKTYP 3419 
4/ VOL OAN4tY 

4/7 LFO OISKIN 

4/7 OPTION SCAN,SUB 


4/7 EXEC USKPRPON 11333302 
4% 11:33:03 
J¢FINISHED NOP 22235103 
46 : ; aie 11333303 
acul JOB CGV ACCT. NO. ASSIGNED MEMORY=00048128 BYTES (PLUS OO3N72 AYTE PROLOGUE) 88/06/07 J08 #0) 11:33:08 
acu2 S80-3 SUPL4G 08.9.1S2 te g@ 11233208 
Jcol v0b C5V EXECUTING JOG STEP WRTRIGOD #ONE 11:33:09 11:33:09 


A2g33238 


ACLQ) = LFU - PRNTR » FORM NAME - STANO] , COPIES - 0002, PAGES - S0000001, STEP =NNL 
12s33226 


ACL STEP #0G1 (wRIBIGIO) USED 39003229 BYTES ELAPSED WALL CLOCK TIME=N0:90:05.1NK& TOTAL S¥C CALLS=9N000290 


acl2 TER* CODE=u90 SWITCH-PRIORITY=05 cpu TIME USED =00:00:01-A98 TRANSTENT CALLS=ONNNOO1S U2s33s14 
ACL3 PST SETTING x*an* Bisd3s24% 
acig OfvIce CacPr*s 1Q8 IGG 701s = PeT=0000NU23 D2s33224% 
JCOl JOu CSv EXECUTING JO2 STEP DSKPRPOD #902 11233315 LisS3325 
USAJT WARNING wHEN CHANGING VSN OF SYSRES, SYS2UN, OR 123333:20 
uSaJT SYSPGOL NO CHECK FOR DUPLICATE VSN IS MADEs LizS3:22 


21233:23 


ACLO LFD - PRNTR » FORM NAME - STAND) , COPIES + GO01, PAGES - OO000001, STEP =002 
11:33:23 


ACLL STEP #U92 COSKPRPIO) YVSEN 8UNG7572 BYTES ELAPSED WALL CLOCK TIME=00:00:08.N93 TOTAL Svc CAaLLS=000N0606 


Cee PPP Peele er PP PP ER PPE OEE POP CER P EE PP PEC RPP FE 


AaCi2 TERM CODE=000 SWITCH-PRIORITY=05 cpu TIME uSEO =00:00:03.181 TRANSIENT CALLS=00000037 1233523 
ACLS) UPST SETTING x*09° * Abe33223 
acig DEVICE EXCP*s 104290000329 PRT=0u000025 . 11233323 
AC21 JOs TOTALS USED OUO8T572 BYTES TOTAL ELAPSED WALL CLOCK TIME=002:00217.129 Tora. Jos S¥C CALLS=00000898 Lirss3328 
AC22 WALL CLOCK TIME OF ALL STEPS 700:00:133.20! J068 TRANSIENT CALLS=0000005) 81233325 
ac23 TOTAL CPU TIME OF ALL STEPS =00:00:06.010 TOTAL JOB EXCP*’sS =00000$21 23233325 
JCO2 JOB CGV TERMINATED NORMALLY 11:33:25 Lis33s26 
Ce ee ee ten ven 


Figure 9-5. Sample Listing for CGV Job (Part 1 of 3) 
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¥ A8Y T¥8SdN 


6€6 








000000 - 9000 0000 44 1 o02u TTTTTTTT «Ananny 
00000000 oa 6300 oad 600 444 111 no 0 YrTTTTyYT 9n0n0n09 
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Figure 9-5. Sample Listing for CGV Job (Part 2 of 3) 


dud\sa 


s ma te ee ———E—————ESS 2 
a] 
ve& 880317 eexeucegeeeeeee OS/3 DISK INITIALIZATION eeetedweeeeeeee 3 
: ~ 
DATE 88/85/08 TIME 11:33:19 


* CONTROL STREAM PAR AMETOOS # 


RPVOL=Y pSERNRIAEL IA) CoVGN220 
VOL csvad23c 


* DEFAULT PAREMETERS © 


ALTRK=Y ILUPT=N Iesrtia TPLGKrZY CARTLIN 
PREPTOF PTAR GT IB PTENC DISET | RETYYSOA T8CON=)D 
TRACTI2 VeRFyos vToCe ase Cand vTCL=IANCAUS = sAUTKTA 
UNXFC=IN FRATOZD 





USAUT wARNING wHEN CHANGING VSN UF SYSRESs SYSIUN, O¥ 
UsSaJT SYSPIIL WO CaAFCK FIR QUPLICATF vss TS MADE. 
USARL NORMAL FOU - OTSK ITS sud 


UNISYS SYSTEM OS/3 DISC INITIALIZATION COMPLETE 
OATE+ 88/05/08 TEME= Dbs33221 uPST= x*97° 
VSN-  RELOwO TYPF- R4akY 





Figure 9-5. Sample Listing for CGV Job (Part 3 of 3). 
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This listing shows the job control for the CGV job, information about it, the old and 
new volume serial numbers in large print, and the parameters that CGV includes for 
your DSKPRP routine. You can keep this listing as a record of the way your disk is 
prepped. After you change a volume serial number, make sure you physically change 
the label on the outside of the disk so the label always shows the correct volume serial 
number. For this sample listing, your command would have been 


RV CGV, ,O=D00410, N=RELO8@, T=19 


Prep and Allocate RELEASE/SYSRES Files (SETREL) 


The SETREL system utility routine prepares a disk volume for use as a RELEASE or 
SYSRES volume. It preps the disk and allocates the standard SYSRES files. The file 
space is allocated according to the type of disk being used. The disk may be prepped 
with or without full surface analysis. The required parameters can be supplied in the 
SETREL command itself or on cards. After executing SETREL, you copy the 
RELEASE or SYSRES volume by executing COPYREL. 


System Console or Workstation Keyin 


SETREL can be run by keying in the following command at the system console when 
it is in console mode or at a workstation in system mode: 


RV SETREL, , V=vsn, T=disk-type,P=prep-typel ,CR=NO] 
Keyword Parameters 


V=vsn 
Specifies the volume serial number of the disk. For a full or partial prep, this 
may be a new VSN to be assigned to the disk. Otherwise, it must be the 
same as the current VSN. If omitted, the card reader is activated to read the 
parameters from cards, as though the RU SETREL command were being 
used. (See “Card Input,” which follows in this section.) 


T=disk- type 
Specifies the type of disk being used, as follows: 


Disk Type Meaning 
16 8416 
17 8417 
18 8418 
19 8419 
30 8430 
33 8470 
70 8470 
94 8494 
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P=prep- type 
Specifies the type of prep to be performed, as follows: 


Prep Type Meaning 


N No prep (assign files only) 
F Full prep (with surface analysis) 
P Partial prep (without surface analysis) 
If omitted, P is assumed. If N is used, the disk must have already been 
prepped. 
CR=NO 


When you enter RV SETREL at the system console and specify a full prep, 
you may enter bad track addresses on cards or interactively at the console. If 
you specify CR=NO, prompt messages are displayed at the console so that 
you can report any known bad tracks by entering their hexadecimal 
addresses. To enter bad track information on cards, use the RU SETREL 
command (see “Card Input,” which follows in this section). 


When you enter RV SETREL to do a full prep from a workstation, prompt 
messages are automatically displayed, so the CR=NO parameter can be 
omitted. 


Omit this parameter when doing a partial prep or no prep. 


Card Input 


Another way to run SETREL is to key in the command at the system console but 
submit the required information on cards. With this method, the cards can contain the 
keyword parameters and the bad track addresses or just the bad track addresses. 
When cards are used, the RU SETREL command (rather than RV SETREL) must be 
used. Also, the command must be entered at the system console when it is in console 
mode. With this method, all files allocated will be release volume size files. 


To run SETREL using cards for keyword parameters and bad track addresses, use the 
following command format: 


RU SETREL 


The cards that must be in the card reader depend on the type of prep being done and 
the type of disk being prepped, as follows: 


¢ Partial prep without surface analysis 
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//PREP JSET '@! 

JINSNO JSET ‘vsn! 
/ITYPE JSET 'disk-type' 
/1 FIN 
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¢ Full prep with surface analysis 


1 18 16 





7/PREP) = JSET '1! 
JIVSNO JSET 'vsn! 
JITYPE JSET ‘disk-type' 


// FIN 
INSERT { NONE 

ceechh 
// FIN 


The values that may be assigned to the various parameters are as follows: 


| vsn i] 
Specifies the volume serial number of the output disk. 


"disk-type' 
Specifies the type of disk subsystem being used. The values are 

Value Disk Type 

16 8416 

17 8417 

18 8418 

19 8419 

30 8430 

33 8433 

70 8470 


NONE 
Indicates that there are no defective cylinders and tracks on the disk. To 
prep a selector channel device disk with no defective tracks, omit the 
INSERTAAANONE statement but still use both // FIN statements. 


ceechh 
Specifies the hexadecimal address of the defective cylinder and track as 
listed on the disk. 


To do a full prep and enter only bad track addresses on cards, include the keyword 
parameters in the SETREL command as follows: 


RU SETREL, , Vevsn, T=disk-type,P=F 
These keyword parameter values are explained earlier in this subsection. The 
INSERTAAANONE or INSERTAAAcccchh cards must be present in the card reader. 
After these, a // FIN card is also needed to turn off the card reader. 


Note: For cardless systems, RU SETREL will read parameters from diskette. 
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9.10.3. Copy System/Release File (COPYREL) 
After successfully prepping and allocating your disk volume that will contain the 
system and release libraries using SETREL, you copy those libraries using COPYREL. 
You execute COPYREL by using the following console keyin: 


RVACOPYREL , , V=vsn, T=disk-type,[,S=first-file][,E=last- file] 





where: 
V=vsn 
Specifies the volume serial number of the output disk being copied. 
T=disk- type . 
Specifies the type of disk subsystem being used. The values are as follows: 
Value Disk Type 
16 8416 
17 8417 
18 8418 
19 8419 
30 8430 
33 8433 
70 8470 
94 8494 
S=first-file 
Specifies the code identifying the first file to be copied. Table 9-5 shows the 
order in which COPYREL copies the system files and shows the codes for 
each system file. These are the only files that can be copied by COPYREL. If 
you omit the S keyword, COPYREL starts copying at $Y$SRC. 
E=last-file 


Specifies the code for the last file to be copied (see Table 9-5). If you omit the 
E keyword, copying ends at $Y$TRANA. 


Note: More detailed discussions of SETREL and COPYREL are found in the 
Installation Guide (UP-8839). 
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Table 9-5. COPYREL Copy Order 












SYSSMCLOG 


15 SYSFMT 

16 SYSSAVE 

17 SYSDIALOG 

18 SYSSDF 

19 SYSHELP 

20 SYSTRAN 
SYSTRANA 
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9.11. Error Processing 


The prep routine always terminates normally, even if errors are detected during the 
execution of your prep. Error messages, however, are listed on the printer. At prep 
completion, the hexadecimal value of the user program switch indicator (UPSD) byte is 
listed on the printer. The UPSI byte indicates the severity of the errors detected. 


When the canned job control streams are run, if unrecoverable errors occur during the 
prepping of the volume, a message is displayed on the console and the job is 
terminated immediately. If other errors are encountered, a warning message is 
displayed, and the job continues processing. 


Note: The console message PREP TERMINATED WITH ERRORS is displayed if the 
UPSI byte is set (40,, or 80,,). However, the prep is completed even though an 
unrecoverable error condition occurred. 
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Section 10 
Assign Alternate Track (AAT) 


10.1. AAT Capability 


The AAT routine is used to conditionally or unconditionally assign an alternate 
track/sector for a suspected defective area on a disk pack. The suspected defective 
track/sector may be either a primary data track/sector or another alternate 
track/sector. Assigned conditionally means that an alternate is assigned only after a 
surface analysis is performed and the analysis shows defects. Assigned 
unconditionally means that no surface analysis is done and the track/sector is 
assigned regardless of its condition. 


Note: The 8494 disk only supports unconditional assignments. 


For conditional assignment, an available alternate track is assigned by AAT and the 
contents of the suspected defective track are copied to it, one record at a time. During 
the copy procedure, any errors detected are listed on the printer. These errors can be 
corrected in subsequent runs of AAT by using the record updating facility, ASUPD. 

@ After the records are copied to the alternate track, a surface analysis is performed on 
the primary track. If the track is found to be defective, it is marked as unusable and 
the alternate track is permanently assigned. However, if the primary track is found to 
be usable, then all the records on the alternate track are copied back to the primary 
track and the alternate track is again made available for use. 


For an absolute or unconditional assignment, the process is similar. The suspected 
defective track/sector is read and the data is saved. Any defective records are printed. 
At this point, the defective track/sector is assigned and the recovered data is 
rewritten. No surface analysis is performed on the suspected track/sector. Remember 
that a suspected defective area can be an alternate as well as a primary track/sector. 
If it is an alternate, another alternate is reassigned as the alternate for the original 
primary data track/sector. The suspected alternate is then assigned to itself so that it 
cannot be used again. 


Caution 


If AAT terminates abnormally, the track condition table (TCT) may be compromised and the 
disk files rendered inaccessible. 
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10.2. Interfacing with DSKPRP 


The AAT function is a feature built into DSKPRP; therefore, you must execute 
DSKPRP (specify DSKPRP on the EXEC job control statement) to use the AAT 
capability. Before assigning any alternate tracks, your disk must have been previously 
prepped. 


10.3. Specifying AAT Options 
There are five keywords associated with the assigning of any alternate tracks. You 


must specify both the ASGTK and SERNR keywords; the remaining keywords are 
optional and have default values. The format of the AAT keywords is 


ASGTK= /ccecchh ,ASGPR={A (8494 only)|||,ASURF=(N (8494 only) 
oe (8494 mp} E s 








ba e | , SERNR=volume-ser ial -number 
Y 





10.3.1. Specifying Any Suspected Defective Tracks (ASGTK) 


Since the AAT capability is a function of the disk prep routine, you must specify 
ASGTK to indicate the function to be performed. You specify the suspected defective 
track in hexadecimal cylinder/head format (cccchh); or, for 8494 disks, the defective 
sector in cylinder/head/record format (cccchhrr). For 8494 disks, you also have the 
option of interactively entering the addresses of the defective sectors by specifying 
ASGTK=M (multiple). If you specify ASGTK=M, a message is displayed requesting 
the disk address (cccchhrr) or END. This interactive method cannot be used if update 
records are specified (ASUPD=Y). 


Remember, you cannot assign an alternate track/sector to an active SYSRES pack. If 
you need to assign alternate tracks/sectors to your SYSRES, another SYSRES or the 
current release volume must be used as the operating system. If you omit ASGTK, the 
disk prep routine is executed; however, the disk prep routine will be terminated 
because there is no VOL1 statement present in the control system. VOL1 cards cannot 
be used in an AAT run. 
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Printing Your Records (ASGPR) 


When reading the records from the track specified by the ASGTK parameter, any 
records detected in error are listed on the printer by the E option automatically. 
However, if you need to print all the records being read, specify the A option. If you 
use the A option in conjunction with the ASUPD=Y keyword, no records will be 
printed. In other words, ASGPR=A has no effect when you specify ASUPD=Y. 
ASGPR=A is the default for 8494 disks; ASGPR=E is the default for all other disks. 


Testing the Alternate Track (ASURF) 


If you recall, you can assign the alternate track conditionally, that is, only after 
ensuring that the primary track is defective, or unconditionally, meaning no surface 
analysis is performed. By omitting ASURF or specifying the S option, alternate tracks 
are assigned conditionally. If you are certain the primary track is unusable, specify 
ASURFEN and no surface analysis will be performed. 


Note: The 8494 disk only supports unconditional assignments. 


Patching or Modifying Existing Records (ASUPD) 


If any errors are detected in the reading of your records from the primary track for 
writing on the alternate track, they are listed on the printer. From this listing, you key 
in the missing information into update records. These update records will then patch 
the incomplete record. However, if the missing information cannot be determined, you 
must recreate your file. 


Whenever update records are present in your control stream, you must specify the 
keyword parameter ASUPD=Y. If there are no update records present, the default 
ASUPDEN is assumed. 


At least two cards are required for each update record; one to identify the record and 
field to be updated and another to contain the correction data. The number of the 
record to be updated must always be specified as a hexadecimal number and must 
always begin in column 1. 


The record numbers on a given track appear on the listing of errors found during the 
recovery of data during a previous AAT run. These records are listed in decimal and 
must be converted to hexadecimal for the update. The length and displacement of the 
field being corrected must also be identified by specifying DATA=({d],L), where d 
represents a displacement value and L represents a length value. 


The displacement value, relative to 0, may be up to four hexadecimal characters long, 
or may be omitted, to indicate that the patch is to be made beginning with the first 
character in the identified record field. The length value must be specified and can be 
from one to four hexadecimal characters long. 
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10-4 


The DATA keyword can be coded on the card containing the number of the record (rn @ 
parameter) to be patched. If coded with the rn parameter, a comma must separate the 
two specifications. If coded alone, the keyword must begin in column 1. 


Thus, the format of an identifier update record could be illustrated as 


ne mam ig) «= ( 


The actual data to be written must be submitted on a separate card apart from the 
update record. The actual data must be in hexadecimal format (0 through 9, 

A through F) and start in column 1. The length of the data must equal the length 
value specified in the DATA parameter. No embedded blanks are permitted and as 
many cards as needed may be used. The first blank character found in the data cards 
indicates the end of the record. The maximum amount of data per line is 80 
hexadecimal digits. 


It should also be noted that only one DATA keyword may appear in any one set of 
update records, and when ASUPD=Y is specified, the ASGPR and ASURF keywords 
are ignored but checked for syntax errors. 


A typical example of an update control stream could look like: 


1 18 16 






Job contro! statements 





/$ 
ASGTK=081A06, SERNR=DSP001 
ASUPD=Y 


18 
DATA=(3C,A) 
C1iC2C3C4C5C6C7C8C9D1 


In this example, record 1B is being updated. There is a displacement value of 60 bytes 
(3C) and a length of 10 bytes (A). The new data being written is specified on a 
separate card and must be in hexadecimal format. If more than one record is to be 
updated, an additional data set is needed for each record. You will see more typical 
examples of using update records in 10.4. 


Specifying the Disk Volume Serial Number (SERNR) 


The volume serial number consists of six alphanumeric characters that make up the 
serial number of the disk volume being used. The SERNR keyword must always be . 
present in your AAT control stream. @ 
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10.4. Executing AAT 


When executing the AAT routine, the same file names that were required in the disk 
prep routine must be specified here. Namely, PRNTR must be specified on the LFD 
job control statement for assigning the printer while DISKIN must be specified for 
assigning the disk. In the following control streams, you will see some typical 


examples of AAT. 
Example 1 
1 18 16 





// JOB AATRACK 
// DVC 20 // LFD PRNTR 
// OVC 51 // VOL REL12@ // LFD DISKIN 
// EXEC DSKPRP 
/$ 
ASGTK=00C 106, SERNR=REL@80 


Here is the basic AAT control stream. The suspected defective track is located on 

. cylinder 00C1, head 06, on disk RELO80. You are omitting the ASGPR, ASURP, 
and ASUPD keywords, thus using the default options. Any records found to be in 
error are listed on the printer (ASGPR=E), a surface analysis is performed on the 
track (ASURF=S), and there are no update records present in your control 
stream. 


Figure 10-1 shows the output generated from this control stream. 





VER 88@317 eeeeenaeeeseeses OS/3 DISC INITIALIZATION eeusececengease 
CATS 88/06/82 TIME 12:56:36 
* CONTROL STREAM PARAMETERS & 


ASGTK=C0C106, SERNR=RELUS9 


* DEFAULT PARAMETERS * 


ALTRK=Y ASGPR=E ASUPD=N ASURF=S ILOSPTIN 
INSRT=N IPLOK=Y PARTL=N PREPT=F PTSEG=00C106 
PTEND=O0C106 WET2Y=I9A RPVOL=N T2CON=D TRKCT=Z 
VERFY=N vTOCB=a9CAIO0 § vISCe=agCAd6 UNXFC=N 





Figure 10-1. Basic AAT (Part 1 of 2) 
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USAOT PRIMARY TRACK SPCCIFIEDS wAS FOUND GOOD BY SURFACE ANALYSIS 





OS/3 TRACK CONDITION TABLE 
SERTAL NUMBER RELOSD 


3YTES FIRST 

ARITTEN BAD: 
ALTE PNATE TRACK CODE EYTE ORIMARY TRACK ON BAD BYTE 3YTE BYTE 
CYLINVER HEAD 3123 4567 CYLINOFQ HEAD TRACK FOUND READ EXPECTED 


wwe ene ge He Oe me meee eer ere ese = ew we ee ROO Hw Oe Oe OOO FE OOH EES POSER Hee eee 


U328 95 1 4 7 9933 33 9009 3000 su. ao 
o32e 31 1 4 7 aQ3F pre 3009 0030 00 00 
G323 52 1 a 7 9104 ar 3c¢0a 0030 ao oo 
0323 03 1 4 7 gocs 33 3030 0030 90 oo 
0328 o4 1 4 7 3153 32 0590 0070 oo oo 
g328 a5 3 6 go03s on 9000 3090 oo oo 
0328 06 2 0300 co 0000 9000 00 00 
0329 oo 2 00039 30 0009 g070 00 00 
3329 a1 2 a900 07 9000 3000 90 oo 
0329 “02 2 9000 oe 0000 0090 00 00 
0329. 03 2 9000 30 oooo 3090 00 oo 
0329 o4 2 ocj0 90 acaa 0030 oa oo 
0329 as 2 0000 a0 9009 0090 00 oo 
0329 96 2 o300 ce ooo00 0000 oo oo 
O32Aa oo 2 oooo0 09 o000 0030 oa Go 
O32A G1 2 0009 ao go30 0000 oo oo 
O32A a2 2 0000 ua ocoo 3009 ao oo 
O32A 03 2 9000 a0 go000 0090 oo 00 
O32a o4 2 0000 ao ao0o 32930 oo oo 
032A Os 2 a000 an 0000 oouod 90 00 
O32A 06 2 ooo0 90 9090 0330 ao 00 
U328 a0 2 aooo 00 oo00 0000 oo oo 
0328 01 2 0000 90 0000 0030 oo oo 
0328 02 2 0000 a0 0009 0000 oo ao 
0328 Q3 2 6000 oo oooo ooo0 oo oo 
0328 _08 2 0000 00 oa00 ooo00 00 oa 
0328 os 2 oo00 oo anao oo00 oo oo 
0328 06 2 0000 00 0000 0000 oo 00 @ 
032C oo 2 aooo oo 9900 a090 00 oo 
o32c cep | 2 0000 oo 0009 0030 00 oo 
a32c 32 2 ouco ao oog00 0000 oo oo 
o32c 03 2 oaco oo oo00 ooao oo oo 
a3s2c o4 2 ooo0c0 oo ao00 0000 oo oo 
932Cc as 2 oooo aa 0000 0009 oo oo 
a32c 06 2 oaao0 oo 0000 0000 oo 00 
&329 90 2 ane rele) oons 3900 aa 00 
329 a1 2 cano a4 0930 9030 90 00 
9329 22 2 39035 20 ag09 6030 30 co 
9323 93 2 $595 70 35090 3000 00 oo 
0320 94 2 309c 50 9cno 2090 00 oo 
a320 95 2 c90 (eke 00909 30990 oo a0 
0329 06 2 Jo739 1G 0909 9099 90 oo 
J32E 33 2 39039 ao goo9 39330 00 00 
u32e 21 2 cars 30 0999 0099 oo oo 
J3ee 92 2 aces ac 3000 3090 60 00 
G32= ~ 93 2 939) we 0903 0090 00 oo 
u32° a4 2 90s or 00u0 3990 oo oo 
332: 35 2 9303 tots} eeoaoog 3039 50 00 
u32e 06 2 1999 ac goo09 9030 30 oo 


BIT Of ALTERNATE TRACK LISTED IS DEFECTIV:. 
1= PRIMARY TRACK LISTCO IS LEFECTIVE AND AN ALTERNATE HAS BEEN ASSIGNED 
2= ALTERNATE TRACK LISTE) IS G500, SUT NOT ASSIGNED 
3= ALTERNATE TRACK LISTED IS GO0D AND HAS 3EEN ASSIGNED BY THIS RUN 
4= THIS DEFEZTTIVE TRACK FOUND 3Y SURFACE ANALYSIS 
S= THIS DEFECTIVE TRACK DJESIGWVATEO 8Y CA26 INSERT 
6= THIS ALT TRACK CONTSINS THE TRACK CINOTN TASLE 
7= THIS ALT TRACK WAS ASSIGNED GY A PREVIOUS RUN 


USAR] “SORMAL EQJU - DISK IS 6900 


UNISYS SYSTEM OS/3 DISC INITIALIZATION COMPLETE 








DATE 88/06/02 TIME- 12:56:41 UPSI- xX*QU* 
VSN- RELOBI TYPE- 8419 
Figure 10-1. Basic AAT (Part 2 of 2) @ 
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1 18 16 





// JOB UPDATE 
// DVC 20 // LFD PRNTR 
// DVC 51 // VOL REL12@ // LFD DISKIN 
// EXEC DSKPRP 
/$ 
SERNR=TST93J 
ASGPR=A 
ASUPD=Y 
ASGTK=00A106 
/* 
/$ 
14, DATA=( ,32) 
11999119991491911999111991111191999111119999111111111111111122333333333444444555 
5555555566778899C8&C9 





. Update records are used to patch specific key and data fields on your disk. The 
@ volume serial number of your disk is REL120, which is equated with the VOL job 
control statement. Since update records are present in your control stream, you 
specified ASUPD=Y. As you can see, all the keyword parameters are part of the 
first data set. The record data set contains the update records themselves. The 
record number in error is 14 (decimal 20). The data being corrected has a length 
of 32,, (decimal 50) bytes and is shown on the next two cards. 


Note: If more than one card of data is required, the previous card must have all 80 
columns in use. 


Figure 10-2 shows the output generated from the control stream. 
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VER 880317 seeeeeeneeseeee 08/3 OISC INITIALIZATION *eeeeeesneeeece 
DATE 88/06/07 TIME 152237243 

* CONTROL STREAM PARAMETERS © 

SERNR= REL120 

ASGPR=A 


ASUPD=Y 
ASGTK=S30A106 


* OEFAULT PARAMETERS * 


ALTRK=Y ASURF=S ILOPT=N INSRT=N TPLOK=Y 
PARTL=N DREPT=IF PTBEG=00A196 PTEND=U0QA106 RETRY=0A 
RPVOL=N TRCON=0 TRKCT=HZ VERFY=N vrocs=00ca00 
VTOCE=00CAQ6 UNXFC=N 


14,DATA=t,32) 
LLLLELLLVDIQLDALALLLLYLELIALALALALALELVALALALAALALAILIAL1111 2233333333 344444 4sss 
5555555566778399C8C9 


USAR1 NORMAL EOJ - OISK IS 6000 





UNISYS SYSTEM OS/3 DISC INITIALIZATION COMPLETE 

DATE- 88/06/07 TIME- 153217346 uPST= x°90°* 

VSN- 2EL080 TYPE- 4419 
Se eS EE EE —— ee ——E—_—— 


Figure 10-2. AAT Using Update Records 
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Section 11 
Tape Prep (TPREP) 


11.1. Preparing Your Tape for Execution 


Magnetic tapes are shipped blank. You must prepare (prep) these tapes before using 
them in OS/3. The tape prep utility (TPREP) can prep up to 36 files and up to 16 
volumes for each file in one job step. It will prep them for use with or without block 
numbers, depending on whether your system is configured to support tape block 
numbering. If your system is configured to support tape block numbering, you have 
the option to prep tapes for tise without block numbers. You cannot, however, prep a 
tape for use with block numbers if your system is not configured to do so. 


You submit all the required information for tape prepping through job control 
statements. TPREP uses the prep facilities of data management to prep your tapes. 
The various tape record formats that are generated by the prep facility can be found in 
the current version of the Consolidated Data Management Programming Guide 
(UP-9978). 


After your tape has been prepped, it is rewound to load point. 


11.2. Tape Prep Coding Instructions 


All the information required for tape prepping is submitted through job control 
statements. The following job control statements are used for tape prepping: 


¢ DVC job control statement 
You must specify a logical unit number for the tape being prepped. The range of 
logical unit numbers is from 90 to 127. An example of the // DVC job control 


statement used when prepping tapes is shown in the following example: 


1 10 16 


ly DVC 90 
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// VOL job control statement ® 


You must specify a unique volume serial number for every tape being prepped. 
The volume serial number can be any alphanumeric character string from one to 
six characters long, other than the word SCRTCH. Immediately following the last 
character of your volume serial number, the character string (PREP) must 
appear. An example of the // VOL job control statement used when prepping tapes 
is shown in the following example: 


1 18 16 


// VOL TAP@28(PREP) 


Note: The parentheses are coded as part of the parameter. 
To prevent your tapes from being prepped for use with block numbers when your 
system is supporting block numbering, you must include an N parameter in your 
//VOL statement as follows: 

1 18 16 


// VOL N,DSP@28(PREP) 


// LBL job control statement 





You specify the // LBL job control statement only when you want to assign a file 
identifier to a tape volume you are prepping. You can assign the same label to 
multiple volumes to prepare for a multivolume file. If you are familiar with the 
// LBL job control statement, then you would have recognized that there is a file 
sequence number parameter used for the numbering of files in a multifile tape 
volume. However, TPREP ignores the file sequence number parameter. An 
example of the // LBL job control statement follows: 


1 18 16 


lw LBL MASTERFILE 


/1 LED job control statement 


You must specify a unique file name for each tape file being prepped. The // LFD 
file name must be in the form TAPExy: under x is any alphanumeric character A 
through Z or 0 through 9; under y is the character A for ASCII mode or blank for 
EBCDIC mode. An example of the LFD job control statement used when 
prepping tapes in both EBCDIC and ASCII modes is shown in the following 
example: 


1 18 16 


// LFD TAPE1 
// LFD TAPE1A 
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/! EXEC job control statement 


You must specify the program TPREP in your // EXEC job control statement to 
start the prepping of one or more tapes using TPREP. The // EXEC job control 
statement calls the tape prep utility from $Y$LOD. You code the // EXEC job 
control statement as follows: 


1 18 16 


lw EXEC TPREP 


The following examples show two tape preps using TPREP. Example 1 shows the job 
control statement for prepping six tapes using two magnetic tape drives. Example 2 
shows the job control statements for prepping six tapes using six different tape drives, 
with the last three tapes oe prepped in ASCII mode. All other tapes are prepped in 


EBCDIC mode. 
Example 1 
1 10 916 
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// SOB TAPEPREP 

// OVC 98 

// VOL TP@@Q1(PREP) , TP@@O2(PREP) , TP@GQ3(PREP) 
// LFD TAPE4 

// DvC 91 

// VOL TP@QO4(PREP) , TP@@5 (PREP) , TP@@BS( PREP) 
// LFO TAPE2 

// EXEC TPREP 





// 3OB TAPEPREP 

// DVC 90 // VOL TAPE@1(PREP) // LFD TAPE1 

// DVC 91 // VOL TAPE@2(PREP) // LFD TAPE2 

// DVC 92 // VOL TAPE@3(PREP) // LFD TAPES 

// OVC 93 // VOL TAPE@4(PREP) // LFD TAPEAA 
// DVC 94 // VOL TAPE@5(PREP) // LFD TAPEBA 
// DVC 95 // VOL TAPEQ@6(PREP) // LFD TAPECA 
// EXEC TPREP 


// FIN 
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All messages are displayed on the system console and are written to the 
communications output printer (COP) if it is available. A typical COP listing 
follows: 


14 JCO1 JOB TAPEPREP EXECUTING JOB STEP TPREP@@@ #001 
15 TP@1 TAPE SP@Q01 (LFDNAME=TAPE1A) PREPPED IN ASCII, NO BKNO 
16 JC@2 JOB TAPEPREP TERMINATED NORMALLY 


The following message is displayed for each tape that is successfully prepped: 


TP@1 TAPE vsn (LFDNAME=filename) PREPPED IN {ASCII , JNO BKNO 
EBCDIC WITH 


The absence of this message for any of the tapes specified in your job or job step 
indicates that the tape has not been prepped because of incorrect job control 
specifications. 


If you are creating a file through data management, you may perform tape prepping 
and file creation in one job step. See the current version of the Consolidated Data 
Management Programming Guide (UP-9978). 
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Disk Dump/Restore Routine (DMPRST) 


12.1. DMPRST Concept 


Many of the program libraries and data files stored on disk are vital to your data 
processing operation. Therefore, it is important to keep backup copies of your data 
handy in case it is lost or destroyed. The disk dump/restore routine (DMPRST) 
enables you to create these backups on disk, tape, diskette, or streaming tape. 


You can execute DMPRST either interactively from a workstation or in a batch 
environment using cards. However, you'll see that the interactive method is easier to 
use. Both the interactive and batch methods accomplish the same result; however, 
there are some differences between what each method supports. These differences are 
listed in Table 12-1. 


Table 12-1. DMPRST Differences between Interactive and Batch Methods 













Modes of processing File Volume and File 

RESTART function Not supported Supported 

Tape-to-tape copy Not supported Supported (volume mode) 
Diskette-to-diskette copy Not supported Supported 





Printer assignment Automatically assigned User responsibility 


Notes: 


1. DMPRST cannot process system files (prefixed by $Y$) on an active SYSRES; i.e., 
the SYSRES pack you are executing from. To process these files, see the cu.:rent 
version of the Installation Guide (UP-8839). 


2. In addition to DMPRST, Unisys also provides three canned job control streams 
(SG@DUFIL, SG@DSFIL, and SG@RUFIL) and a standalone routine (SU@RST) 
that you can use to dump and restore your disk files. These are most useful when 
you are continually making backup copies of your files. Even though they are 
designed as a post-SYSGEN procedure for backing up SYSRES files, you can use 
them for any program file. For more information, see the Installation Guide 
(UP-8839). 
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12.2.1. 
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3. The standalone dump/restore program (SU@RST) is used during system 
installation to read diskettes or tapes (models 8 through 20 only) created in file 
mode by the standard dump/restore program and write tracks of data to fixed 
disks. The program also copies the VTOC when requested by the user. SU@RST 
cannot process tapes created with multiple disk volume input. 


4. Before running DMPRST with a supervisor that is not configured to the specific 
system hardware, be sure to turn on the drive(s) for the input (output) disk(s) being 
prepped. This reconfigures the information in the PUB(s). Otherwise, the job uses 
the current PUB information, which may not be representative of the disk(s). 


When dumping a disk in volume mode, DMPRST must be the only job running if the 
I/O device is either SYSRUN or SYSRES. If the device is not SYSRUN or SYSRES, it 
must be set to nonshareable using the SET IO operator’s command. Refer to the 
Operations Guide (UP-8859) for details. Making the device nonshareable ensures that 
an exact copy is made. 


DMPRST Procedures 


You can use two basic DMPRST procedures to create backups. 

1. Disk copy 

2. Dump/restore 

Perform both procedures using the DMPRST routine. However, the devices involved 
and the physical creation of the backup in each procedure are different. 

Disk Copy Procedure 

The disk copy procedure involves a single DMPRST disk copy operation. Here, you are 
copying a disk or a portion of a disk to a disk of the same type. For example, if you are 
backing up an 8417 disk volume by performing a disk copy operation, your backup 
disk must be another 8417 disk. 

Since the disk you are using to store the backup in a disk copy operation is the same 
type as the original, the data is copied to the backup exactly as it appears on the 


original. So, if your original data is lost, you can mount the backup disk and use it in 
place of the original. 
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12.2.2. Dump/Restore Procedure 


You use the dump/restore procedure when the backup device is a different type than 

the original. In this case, you must ran DMPRST twice: first to dump the contents of 
the disk or disks to a backup device and again to restore the contents of the backup to 
the original disk or disks, or to a disk or disks of the same type as the original. 


The backup device created by the dump operation cannot be used directly on the 
system because the data is formatted differently on the backup device. Only the 
restored device can be used. 


Normally, only one disk (or files from one disk) can be dumped/restored. However, 
multidisk volumes can be dumped/restored to tape in a multidisk environment (see 
12.3). If you are backing up a multidisk volume file, you must dump it to tape by 
running DMPRST in a multidisk volume environment, or you must dump it from each 
disk with a separate execution of DMPRST. Output from multiple executions of 
DMPRST should not be written to the same tape or to the same sequential file on disk 
or diskette. 


Dump restore supports streaming tape the same as it supports any other magnetic 
tape device used to create backups for your data. The streaming operation of this 
device when running in its default mode of 100 ips is only guaranteed when you 
execute the DMPRST routine in a dedicated environment. To utilize the streaming - 
capability of this device when executing DMPRST in a nondedicated environment, 
operate the unit at its low speed mode of operation (25 ips). 


Notes: 


1. Since alternate track processing is transparent to DMPRST, to restore a disk pack 
containing $IPL and $IMPL files, you may need to use the DSKPRP routine. See 
Section 9 for more information. 


2. Tapes created from an 8430/33 disk on Release 8.2 and subsequent releases cannot 
be used to restore the disk on releases prior to Release 8.2. 


3. Tapes created by dumping files from multidisk volumes cannot be used by 
DMPRST on releases prior to Release 12.0, nor can they be used by any release of 
SU@RST. 


12.2.3. Tape and Diskette Copy Operations 


In addition to the disk copy and dump/restore operations, the DMPRST routine also 
performs tape-to-tape and diskette-to-diskette copy operations. The tapes and 
diskettes used in these operations must be created by a previous DMPRST operation. 
Tape-to-tape copy operations, however, can only be performed in the volume mode in a 
batch environment. Diskettes must be prepped as data set label diskettes having a 
record size of either 128 or 256 bytes. 
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12.3. Executing DMPRST in an Interactive Environment @ 


Interactive processing of the DMPRST routine consists of a question and answer 
session (dialog). The answers you give tell the DMPRST routine what function to do, 
assign the necessary input and output devices, and cause DMPRST to be executed in 
the file mode. The DMPRST routine supplies default values whenever possible. Any 
errors detected are blinked on the screen with explanatory messages. 


Help screens are provided for all work screens. To obtain HELP for any screen, press 
function key 13. To return to the work screen, press function key 14 or the XMIT key. 
If multiple help screens are being displayed, press the XMIT key after each help 
screen. When the last help screen is displayed, press the XMIT key or function key 14 
and the current screen is redisplayed. 


After DMPRST is executed, a summary report is automatically printed. The 


workstation is freed from the job executing DMPRST after the last screen is processed 
and is noted by displaying the following informational message screen (HU25): 


HARDWARE UTILITIES HU25 


THE INTERACTIVE INTERFACE FOR THIS PROGRAM 


HAS NOW BEEN COMPLETED. THIS WORKSTATION WILL BE 
AVAILABLE FOR USE WHILE THE PROGRAM PROCESSES AS 
YOU REQUESTED. 





To conduct an interactive dialog with the DMPRST routine, you must: 

¢ Log on to the system by keying in the LOGON command. 

¢ Initiate the dialog by keying in the HU command (in system mode). 
¢ Display the menu screen (first screen) by pressing the XMIT key. 


If your system is a model 3 through 6, menu screen HUOOB is displayed. If your 
system is a model 8 through 20, menu screen HUOOC is displayed. 


Hardware Utilities Menu HUOOB (Models 3 through 6) 


HARDWARE UTILITIES 


DUMP FILES FROM A DISK(S) 
RESTORE FILES TO A DISK(S) 
LIST FILES ON A BACKUP MEDIUM 
COPY FILES FROM DISK TO DISK 
COPY AND/OR VERIFY 8419 DISK 
NONE OF THESE 





ENTER SELECTION 
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Hardware Utilities MENU HUOOC (Models 8 through 20) 


HARDWARE UTILITIES HUG@C 


- DUMP FILES FROM A DISK(S) 

. RESTORE FILES TO A DISK(S) 

« LIST FILES ON A BACKUP MEDIUM 
. COPY FILES FROM DISK TO DISK 


- COPY AND/OR VERIFY 8419 DISK 

- COPY AND/OR VERIFY 8416/8418 DISK 
. COPY AND/OR VERIFY 8430/8433 DISK 
- NONE OF THESE 


On Our WwWn = 


ENTER SELECTION 





The procedure for executing DMPRST in an irteractive environment is the same for 
all models of System 80. The HUOOC menu offers two additional copy operations 
(8416/8418 and 8430/8433 disks) that are not applicable to models 3 through 6. Any 
differences in the screens displayed in a procedure are noted when applicable to a 
particular model. 


The next set of screens displayed depends on the particular operation you select from 
the menu. To make a selection, key in the appropriate number for the operation you 
want to perform and press the XMIT key; DMPRST does the rest. 


Typical examples using the copy, dump, restore, and list DMPRST functions (numbers 
4,1, 2, and 3) are described in 12.3.1 through 12.3.4. Examples of the other copy 
operations (numbers 5, 6, and described in Section 15. When pals at the 
screens, the default values are jand user entries are shown in 








Performing a Disk Copy Operation 

During a disk copy operation, you copy the contents of a disk to another disk of the 
same type. You perform a disk copy by keying in 4 from the selections on the hardware 
utilities menu screen (see 12.3). Up to four screens can be displayed. They are 


e Screen 1 (HU00BI03) is an informational screen that tells you that the 
interactive job you selected has been initiated. 


e Screen 2 (HU12) asks you to specify the input and output device information. 
e Screen 3 (HU16) asks you to specify the file options that are in effect. 


e Screen 4 (HU17) appears only if individual files are being copied and it asks you 
for the file name, relocation option, and rename specifications. 


Now, let’s look at a typical disk copy operation. 
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Screen 1 (HUOOBIO3): Informational Message 


HUS@BI@3 
A CONVERSATIONAL JOB CHUSCPY) TO COPY FILES FROM ONE DISK TO 


ANOTHER WILL BE INITIATED IN YOUR BEHALF. YOU MUST BE IN SYSTEM 
MODE FOR THE JOB TO BE SCHEDULED. IF YOU ENTERED HARDWARE 


UTILITIES THROUGH THE HU COMMAND YOU WILL BE IN SYSTEM MODE 
AFTER TRANSMITTING. IF YOU ENTERED THROUGH THE MENU COMMAND YOU 
ARE RESPONSIBLE FOR GOING INTO SYSTEM MODE. 

“week TRANSMIT TO CONTINUE ***** 


This is an informational screen. Read it and press the XMIT key to continue. 


Screen 2 (HU12): Input and Output Devices 








COPY INPUT-OUTPUT DEVICE INFORMATION 








ENTER SPECIFIC INPUT DISK DEVICE TYPE: 84 19 


ENTER INPUT VOLUME SERIAL NUMBER: 







ENTER SPECIFIC OUTPUT DISK DEVICE TYPE: 84 19 


ENTER OUTPUT VOLUME SERIAL NUMBER: 





weeeeeeees FUNCTION KEYS: FI3=HELP, FI4=EXIT HELP ***eeeeee 





Looking at Screen 2, we see that both our input and output device type is 8419, our 
input volume serial number is PUBDSK, and our output volume serial number is 
REL120. Since we don’t need any help, press the XMIT key. 


Screen 3 (HU16): File Options 


HU16 


WAIT FOR UNLOCK WAIT=Yq 


COPY ALL FILES ALL=NO 
UNEXPIRED FILE CHECKING UNXF=YES 


WweRRRER FUNCTION KEYS: FIS=HELP, FI4=EXIT HELP ******4% 


We enter NO in Screen 3 to override the default YES for the WAIT FOR UNLOCK 
option. This indicates that, if the file is unavailable to be locked, skip the file and 


continue to the next one. Any files skipped will have their file names listed on the 
printer. 
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Since we do not want to copy all the files, we accept the default NO. This provides for 
file selection. . 


Finally, if we want to select UNEXPIRED FILE CHECKING, we press the XMIT key 
(assuming the default YES). This option prevents copying over any files on the output 
volume whose dates have not expired. (The expiration date was generated at file 
creation time using the // LBL job control statement.) 


Screen 4 (HU17): Specifying Input File Names 


ENTER 
-P IF FILENAME IS THE 16-BYTE PREFIX OF A GROUP OF FILES 

=F ILENAME , ALLOCATION, NEWNAME 

FILE _ _ 


FILE _ 
FILE _ 


ARE MORE FILES TO BE ENTERED? NO 


weeeeREARAEUNCTION KEYS: FIZ=HELP, FIG=EXIT HELP *###teeeee 





Here, we specify our input file names as CPYLIB and MENUFILE. Any other files 
residing on our volume are not copied. You also have the option of specifying a file 
prefix rather than the entire file name. To indicate a prefix, enter .P immediately 
before the equals sign (=); enter the prefix name (up to 16 characters) immediately 
after the equals sign. Since we don’t need to copy our file to a specific area on our 
output volume, we ignore the ALLOCATION and NEWNAME options and press the 
TAB key to the next query ARE MORE FILES TO BE ENTERED? Since we are only 
copying two files, we press the XMIT key. The processing of our files begins. When the 
processing is completed, a summary report is produced for the operation. 


Notes: 


1. Ifyou answered YES to COPY ALL FILES on Screen 3 (HU16), then Screen HU34 
is Screen 4 instead of HU16. Screen HU34 requests an allocation option to be 
applied to all the files to be copied. All active files listed in the VTOC are copied. 


2. The file allocation parameters are described in the following listing. For a 
complete description, see 12.5.3. 


ABS Locate a file on the same absolute extents. If a file cannot be allocated to 
the same extents, an error message is displayed, the file is bypassed, and 
processing continues. 
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REL Requests that the file be relocated to a file the same size as the original. 


LOG Relocates a file and deletes all unassigned space for that file. This option 
deletes only space that is not assigned to a pariition control appendage 
(PCA). 


PRE Relocates a file in a space that was preallocated. This space can be 
located anywhere on the disk. 


Omit Standard restore processing - DMPRST scratches the file from the output 
disk and makes up to three attempts to reallocate it on the disk. 


12.3.2. Performing a Dump Operation 


The dump operation copies the contents of your disk volume to a MIRAM file on a 
diskette, another type of disk, or a tape. (If the output medium is tape, files from 
multidisk volumes can be dumped.) Later, a restore operation is required to copy the 
data back from your MIRAM file to your original disk volume in executable format. 
We discuss the dump operation for both single-disk and multidisk volumes here and 
the restore operation in 12.3.3. 


You perform a dump operation by keying in J] from the selections on the menu screen. 
Up to seven additional screens can be displayed. They are 
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Screen 1 (HUOOBIO01) is an informational screen that tells you that the 
interactive job you selected has been initiated. 


Screen 2 (HU18) asks you for the input disk device type. 

Screen 3 (HU19) asks you for the output device type. 

Screen 4 (HU26 or HU27) asks you to specify the input volume serial number(s). 
Screen HU26 also requests a disk identifier for each volume to associate it with 


the files to be dumped from it. 


Screen 5 (HU20 or HU21) asks you to specify your output volume serial numbers 
and the MIRAM file name, when appropriate. 


Screen 6 (HU22 or HU28) asks you to specify the file options. 


Screen 7 (HU23 or HU29) only appears if individual files are being dumped 
rather than dumping all the files on the volume. It asks for the file names. Screen 
HU29, which is displayed for multidisk input, also requests the file identifier for 
the disk from which each file is to be dumped. 
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Performing a Single-Volume Disk Dump Operation 


Screen 1 (HUOOBIO]): Informational Message 


HU@@BI91 


A CONVERSATIONAL JOB (HUSDMP) TO DUMP FILES FROM DISK(S) WILL BE 
INITIATED IN YOUR BEHALF. YOU MUST BE IN SYSTEM MODE FOR THE JOB 
TO BE SCHEDULED. IF YOU ENTERED HARDWARE UTILITIES THROUGH THE 
HU COMMAND YOU WILL BE IN SYSTEM MODE AFTER TRANSMITTING. 
IF YOU ENTERED THROUGH THE MENU COMMAND YOU ARE RESPONSIBLE FOR 
GOING INTO SYSTEM MODE. 

keke TRANSMIT TO CONTINUE ***** 





This is an informational screen. Read it and press the XMIT key to continue. 


Screen 2 (HU18): Defining Input Device 










DUMP INPUT DEVICE INFORMATION 


ENTER INPUT DISK DEVICE TYPE: (aK 


wwaeeeeRe FUNCTION KEYS: FI3=HELP, FIG=EXIT HELP *****e2% 


On Screen 2, we indicate that our disk device type is an 8419. No help is required, so 
press the XMIT key. 


Screen 3 (HU19): Specifying Output Device Type 


DUMP OUTPUT DEVICE INFORMATION 


ENTER OUTPUT DEVICE TYPE (TAPE, DSKT OR SPECIFIC DISK TYPE): 


wewekeeee FUNCTION KEYS: FIS=HELP, F1I4=EXIT HELP *****#88 





Here, we indicate that output is to be written to diskette. (In 12.3.3, we use these 
same diskettes as input for the restore operation.) Since no help is needed, press the 
XMIT key. 


When you dump files to diskette, the diskette must be prepped as a data set label 
diskette with a block size of 256 or 128 bytes. You should also use the default 
FDATA=Y prep option to allocate the entire diskette as one file called DATA. 
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If you want to use a file name other than DATA, you must prep the diskette using the 
FDATAEN prep option. Then you must allocate this MIRAM file in blocks using the 
interactive services ALLOCATE command. To determine the number of blocks 
required for the diskette file, use the following formula: 


number of cylinders number of surfaces track capacity _ total number of bytes 
being dumped from disk x (tracks) per disk x (bytes per track)” being dumped from disk 


total number of bytes . diskette block size _ number of diskette 
being dumped from disk ~ (bytes per block) ~ plocks required 


To determine the number of cylinders being dumped from disk, use an interactive 
services VTOC command. The number of surfaces per disk and the track capacity 
depend on the disk type. The diskette block size must be either 256 or 128 bytes. For 
these variable values, see the Consolidated Data Management Programming Guide 
(UP-9978). , 


Screen 4 (HU27): Specifying Input Volume Serial Number 


DUMP INPUT VOLUME INFORMATION 


ENTER THE INPUT VOLUME SERIAL NUMBER: 


weeweewee® FUNCTION KEYS: FIZ=HELP, FIG=EXIT HELP ******** 





On this screen, we identify the volume serial number of the disk from which the files 
are to be dumped as REL120. 


Screen 5 (HU21): Specifying Output Volume Serial Number(s) 


DUMP OUTPUT VOLUME INFORMATION HU21 


ENTER OUTPUT VOLUME SERIAL NUMBER(S) OR IDENTITY OF GROUP OF VOLUMES 


ENTER Y IF THIS IS THE IDENTITY OF A GROUP OF VOLUMES: N 


ENTER FILE NAME: BiNgS 





weeneeee FUNCTION KEYS: FI3SHELP, FIG=EXIT HELP ****#ee8 
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On this screen, we identify where the data is to be dumped. We can do this by listing 
volume serial numbers for all output volumes or by referencing them all by one group 
name (or identity). To specify volume serial numbers, list them in order on the lines 
provided. Up to 16 volume serial numbers can be listed. If you have more than 16 
output volumes, you must use a group name. A group name can contain up to six 
characters and the first must be a letter. 


In our example, we enter the volume serial number of the output diskette, D07098. 
Then we press the TAB key to get to the next question. We are using the volume serial 
number for the diskette, not a group name. Therefore, we keep the default value (N) 
and press the TAB key to the next field. Here, we enter the file name DATA. We do 
not need help, so we press the XMIT key to transmit these entries. 


Note: The output file specified for the ENTER FILE NAME entry must be allocated 
Prior to the execution of the dump operation. 


Screen 6 (HU22): File Options 


HU22 


WALT FOR UNLOCK WAIT=YES 
DUMP ALL FILES ALL=NO 


weekeRRE FUNCTION KEYS: FI3=HELP, FI4=EXIT HELP *******% 





On this screen, we accept the default values, YES for WAIT FOR UNLOCK (waiting 
for our file to be available) and NO for DUMP ALL FILES. Press the XMIT key. 


Screen 7 (HU23): Specifying Input File Names 













DUMP 





HU23 
ENTER 


-P IF FILENAME IS THE 16-BYTE PREFIX OF A GROUP OF FILES 









FILE 
FILE 
FILE _ 


ARE MORE FILES TO BE ENTERED? NO 
ReRRERRRREUNCTION KEYS: FIS=HELP, FIG=EXIT HELP **#***##** 





On this screen, we enter our input file name TESTIN. Since this is the only file being 
dumped, we accept the default NO for more files to be entered. Press the XMIT key. 
Processing begins. After our job is finished, a summary report is produced. 


Note: When dumping all files, only active files listed in the VTOC are dumped. 
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Performing a Multidisk Volume Dump Operation 
Now, let’s perform a multidisk volume dump to tape operation. 


Screen 1: (HUOOBIO1) Informational Message 







HU@@B 124 





A CONVERSATIONAL JOB (HUSDMP) TO DUMP FILES FROM DISK(S) WILL BE 
INITIATED IN YOUR BEHALF. YOU MUST BE IN SYSTEM MODE FOR THE JOB 
TO BE SCHEDULED. IF YOU ENTERED HARDWARE UTILITIES THROUGH THE 
HU COMMAND YOU WILL BE IN SYSTEM MODE AFTER TRANSMITTING. 

IF YOU ENTERED THROUGH THE MENU COMMAND YOU ARE RESPONSIBLE FOR 
GOING INTO SYSTEM MODE. 

week TRANSMIT TO CONTINUE ***** 









This is an informational screen. Read it and press the XMIT key to continue. 


Screen 2: (HU18) Defining Input Device 


DUMP INPUT DEVICE INFORMATION 


ENTER INPUT Di'SK DEVICE TYPE: 


wkekeEeE FUNCTION KEYS: FIS=HELP, FIG=EXIT HELP ******8# 





On Screen 2, we indicate that our disk device type is an 8419. No help is required, so 
press the XMIT key. 


Screen 3 (HU19): Specifying Output Device Type 


DUMP OUTPUT DEVICE INFORMATION HU19 


ENTER OUTPUT DEVICE TYPE (TAPE, DSKT OR SPECIFIC DISK TYPE): af 


wwwaweeee FUNCTION KEYS: FIZ=HELP, FIG=EXIT HELP ****#**** 





Here, we indicate that output is to be written to tape. Since no help is needed, press 
the XMIT key. 
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® Screen 4 (HU26): Specifying Input Volume Information 


DUMP INPUT VOLUME INFORMATION HU26 


ENTER DISK IDENTIFIERS (D@1-D16) AND INPUT VOLUME SERIAL NUMBERS 
(DISK IDENTIFIERS ARE ONLY REQUIRED FOR MULTIPLE INPUT VOLUMES): 


of] : Rize 


ekkanene FUNCTION KEYS: F13=HELP, F1I4=EXIT HELP awennene 





On this screen, we specify the disk identifiers and the volume serial numbers of the 
disks from which the files are to be dumped. 


Screen 5 (HU20): Specifying Output Volume Serial Number(s) 


& OUMP OUTPUT VOLUME INFORMATION 


ENTER OUTPUT VOLUME SERIAL NUMBER(S): 


weweawee® FUNCTION KEYS: FIS=HELP, FI4SEXIT HELP *#****0% 





On this screen, we identify where the data is to be dumped by listing volume serial 
numbers in order on the lines provided. In our example, we enter the volume serial 
number of the output tape, T07098. We do not need help, so we press the XMIT key. 


Screen 6 (HU28): File Options 


HU28 


WAIT FOR UNLOCK WALT=YES 


wateeeee FUNCTION KEYS: FI3=HELP, FI4=EXIT HELP ****eee2 





© 
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On this screen, we accept the default value YES for WAIT FOR UNLOCK (waiting for @ 
our file to be available). Press the XMIT key. 


Screen 7 (HU29): Specifying Input File Names 


ENTER 


ONN WHERE NN IS THE IDENTIFIER OF THE DISK FROM WHICH THE FILES 
ARE TO BE DUMPED 


-P IF FILENAME IS THE 16-BYTE PREFIX OF A GROUP OF FILES 


=F ILENAME 


ARE MORE FILES TO BE ENTERED? NO 


saeennee FUNCTION KEYS: — FI3SHELP, F14=EXIT HELP reweninin 





On this screen, we enter our input file names. Since these are the only files being 
dumped, we accept the default NO for more files to be entered. Press the XMIT key. 
Processing begins. After our job is finished, a summary report is produced. 


12.3.3. Performing a Restore Operation 
After you have successfully completed the dump operation, you must use the restore 
operation to use the disk on the system. You execute the restore operation by keying 
in @ from the selections on the menu screen. Up to seven additional screens can be 


displayed. These screens are 


¢ Screen 1 (HUOOBIO2) is an informational screen telling you that the interactive 
job you selected has been initiated. 


¢ Screen 2 (HU02) asks you to specify the input device type. 


e Screen 3 (HU03 or HU04) asks you for your input volume serial numbers and the 
MIRAM file name (if required). 


e Screen 4 (HU05) asks you for the output device type, which must be the same 
device type as the original file that was dumped. , 
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@ ¢ Screen 5 (HU30 or HU31) asks you for the output volume serial number(s). 
Screen HU31 also requests a disk identifier for each volume to associate it with 
the files to be restored to it. 


¢ Screen 6 (HU06, HU07, or HU32) asks you to specify the file options. 


e Screen 7 (HU08 for single-disk input, HU33 for multidisk input, or HU34 if you 
are restoring all files). Screen HU08 or Screen HU33 asks you for the file names 
if you are restoring individual files; Screen HU33 also asks you for the identifier 
of the disk to which the file is to be restored. Screen HU34 requests the type of 
file allocation if you are restoring all files. 


Performing a Single-Volume Disk Restore Operation 


Now, let’s do a typical single-volume restore operation. Remember, in the first dump 
example, we used diskettes as our output medium. These same diskettes are now used 
as our input medium for our restore operation. 


Screen 1 (HUOOBIO2): Informational Message 


HU@@BI 02 

A CONVERSATIONAL JOB (HUSRST) TO RESTORE FILES TO DISK(S) WILL BE 

INITIATED IN YOUR BEHALF. YOU MUST BE IN SYSTEM MODE FOR THE JOB 
@ TO BE SCHEDULED. IF YOU ENTERED HARDWARE UTILITIES THROUGH THE 

HU COMMAND YOU WILL BE IN SYSTEM MODE AFTER TRANSMITTING. 

IF YOU ENTERED THROUGH THE MENU COMMAND YOU ARE RESPONSIBLE FOR 

GOING INTO SYSTEM MODE. 

eeeee TRANSMIT TO CONTINUE ***** 





This is an informational message screen. Read it and press the XMIT key to continue. 


Screen 2 (HUO2): Input Device Type 


RESTORE INPUT DEVICE INFORMATION HUG2 


ENTER INPUT DEVICE TYPE (TAPE,DSKT OR SPECIFIC DISK TYPE): 


wwwniiee FUNCTION KEYS: FI3SHELP, FIG=EXIT HELP **#*eee® 





The device type is diskette. Help is not required, so press the XMIT key. 
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Screen 3 (HUO4): Input Volume Serial Number 














RESTORE INPUT VOLUME INFORMATION HUG4 


ENTER INPUT VOLUME SERIAL NUMBER(S) OR IDENTITY OF GROUP OF VOLUMES: 


ENTER Y IF THIS IS THE IDENTITY OF A GROUP OF VOLUMES: N 
ENTER FILE NAME: Lag 
bhesiahabck td FUNCTION KEYS: F13=HELP, F14=EXIT HELP Saereree 








On this screen, we identify the input device. We can do this by listing volume serial 
numbers for all input volumes or by referencing them all by one group name (or 
identity). To specify volume serial numbers, you list them in order on the lines 
provided. Up to 16 volume serial numbers can be listed. If you have more than 16° 
input volumes, you must use a group name. A group name can contain up to six 
characters and the first must be a letter. 


In our example, we enter the volume serial number of the input diskette, D07098. 
Then we press the TAB key to get to the next question. We are using the volume serial 
number for the diskette, not a group name. Therefore, we keep the default value (N) 
and press the TAB key to the next field. Here, we enter the file name DATA. We do 
not need help, so we press the XMIT key to transmit these entries. 


Screen 4 (HUO5): Output Device Type 


RESTORE OUTPUT DEVICE INFORMATION 


ENTER OUTPUT DISK DEVICE TYPE: Sake 


weawkeee ~~ FUNCTION KEYS: FI3=HELP, FI4=EXIT HELP 9 ****eeewe 





We indicate our device type is an 8419 disk. Press the XMIT key. 


Screen 5 (HU30): Output Serial Number 


RESTORE OUTPUT VOLUME INFORMATION 


ENTER THE OUTPUT VOLUME SERIAL NUMBER: 


weaeeeee ~~ FUNCTION KEYS: FI3=HELP, FIG=EXIT HELP *****#e* 





On this screen, we specify the volume serial number of the disk to which the files are 
to be restored. 
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Screen 6 (HUO6): File Options 


RESTORE 


WAIT FOR UNLOCK WAIT=YES 
RESTORE ALL FILES ALL=NO 


UNEXPIRED FILE CHECKING UNXF=YES 
STARTING FROM VOLUME OTHER THAN ONE ANY=NO 


weeeweee FUNCTION KEYS: FIS=HELP, FIG=EXIT HELP ****##** 





On this screen, we take the default values for all file options and press the XMIT key. 
Our result is 


¢ DMPRST will not start processing until the file becomes available. 
¢ Only the files specified are restored. 

e File expiration date is checked on the output volume. 

¢ Restoration starts with the first volume. 


Note: If you specify ALL on Screen 6 (HU06), Screen 7 is HU34, otherwise Screen 7 is 
@ HU08. Screen HU94 is illustrated following HUO8. 


Screen 7 (HUO8): Specifying Output File Names (Selected Files) 


RESTORE 
ENTER 


«P IF FILENAME IS THE 16-BYTE PREFIX OF A GROUP 
=F ILENAME , ALLOCATION , NEWNAME 


FILE__ = free 


ARE MORE FILES TO BE ENTERED? NO 


_ weweewee FUNCTION KEYS: FI3=HELP, FIG=EXIT HELP 9 ***##8e® 





On this screen, we specify our file name as TESTIN. If you recall, this is the file 
dumped to diskette during the dump operation. Since this is the only file being 
dumped, move the cursor to the bottom of the screen and press the XMIT key. 


UP-8841 Rev. 4 12-17 





Disk Dump/Restore Routine (DMPRST) 





After pressing XMIT, the restore operation is executed and, upon completion, a 
summary report is produced indicating that the job was terminated. 


Note: When restoring files from tape, diskette, or sequential files on disk, the restore of 
files with the same prefix will terminate when the first file without that prefix is 
encountered on the input medium or at the end of the input file. The next file 
statement, if any, is then processed. 


Screen 7 (HU34): Restoring All Files 


RESTORE 


SELECT TYPE SPACE ALLOCATION TO BE USED FOR ALL FILES: yeas 


ABSolute - SAME SPACE FILE OCCUPIED WHEN DUMPED 
RELocate - RELOCATE IF POSSIBLE 
LOGicat - SUFFICIENT SPACE TO ALLOCATE SPACE ALREADY 
ASSIGNED TO LOGECAL PARTITIONS 
PREallocated - SPACE IS ALREADY ALLOCATED ON THE DISK 
BLANK - USE FIRST SUCCESSFUL OF THE FIRST THREE METHODS 
OF ALLOCATION 


weweeeee FUNCTION KEYS: FIS=HELP, FIG=EXIT HELP 9 ******** 





Screen HU34 asks you to select a global allocation parameter. 


Performing a Multidisk Volume Restore Operation 
Now, let‘s do a typical multidisk volume restore from tape operation. 


Screen 1 (HUOOBIO2): Informational Message 


HUBOBIe2 
A CONVERSATIONAL JOB (HUSRST) TO RESTORE FILES TO DISK(S) WILL BE 
INITIATED IN YOUR BEHALF. YOU MUST BE IN SYSTEM MODE FOR THE JOB 
TO BE SCHEDULED. IF YOU ENTERED HARDWARE UTILITIES THROUGH THE 


HU COMMAND YOU WILL BE IN SYSTEM MODE AFTER TRANSMITTING. 
IF YOU ENTERED THROUGH THE MENU COMMAND YOU ARE RESPONSIBLE FOR 
GOING INTO SYSTEM MODE. 

weeee TRANSMIT TO CONTINUE ***** 





This is an informational message screen. Read it and press XMIT key to continue. 
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Screen 2 (HUO2): Input Device Type 


RESTORE INPUT DEVICE INFORMATION 


ENTER INPUT DEVICE TYPE (TAPE,DSKT OR SPECIFIC DISK TYPE): 


wewRHRER FUNCTION KEYS: FIZ=HELP, FIG=EXIT HELP 9 ***#e#e 





The device type is tape. Help is not required, so press the XMIT key. 


Screen 3 (HUO3): Inpu: Volume Serial Number 


RESTORE INPUT VOLUME INFORMATION HU@3 


ENTER INPUT VOLUME SERIAL NUMBER(S) OR IDENTITY OF GROUP OF VOLUMES: 


SSeerene FUNCTION KEYS: F13=HELP, F14=EXIT HELP REREEE RE 





On this screen, we identify the input device by listing volume serial numbers for all 
input volumes. 


Screen 4 (HU05): Output Device Type 


RESTORE OUTPUT DEVICE INFORMATION 


ENTER OUTPUT DISK DEVICE TYPE: 


waeekeeee FUNCTION KEYS: FIS=HELP, FIG=EXIT HELP 9 **#**eeHe 





We indicate our device type is an 8494 disk. Press the XMIT key. 
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Screen 5 (HU31): Output Serial Number 


RESTORE OUTPUT VOLUME INFORMATION HU31 


ENTER DISK IDENTIFIERS (0@1-D16) AND OUTPUT VOLUME SERIAL NUMBER(S) 
(DISK IDENTIFIERS ARE REQUIRED WHEN RESTORING FROM A TAPE CREATED 
FROM MULTIPLE INPUT VOLUMES; THEY SHOULD NOT BE USED WHEN RESTORING 
FROM A TAPE CREATED FROM A SINGLE DISK INPUT): 


of : BZEE D 


of: 


MESEEEES FUNCTION KEYS: F13=HELP, F14=EXIT HELP Seeeneee 





On this screen, we specify the disk identifier(s) and volume serial number(s) of the 
disk(s) to which the files are to be restored. 


Screen 6 (HU32): File Options 





RESTORE HuU32 


WAIT FOR UNLOCK WAIT=YES 


UNEXPIRED FILE CHECKING UNXF =f 


Weeenwee FUNCTION KEYS: FIS=HELP, FIG=EXIT HELP ******8# 





On this screen, we take the default values for all file options and press the XMIT key. 


Our result is 
¢ DMPRST will not start processing until the file becomes available. 


¢ File expiration date is checked on the output volume. 
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Screen 7 (HU33): Specifying Output File Names 


RESTORE HU33 
ENTER 


ONN WHERE NN IS THE IDENTIFIER OF THE DISK TO WHICH THE FILES 
ARE TO BE RESTORED 


-P IF FILENAME IS THE 16-BYTE PREFIX OF A GROUP 
=F ILENAME , ALLOCATION , NEWNAME 


ARE MORE FILES TO BE ENTERED? NO 





S*RRRESESFUNCTION KEYS: FI3=HELP, F14=EXIT HELP ****eeeew 





On this screen, we specified the output files. Since they are the only files being 
dumped, move the cursor to the bottom of the screen and press the XMIT key. 


After pressing XMIT, the restore operation is executed and, upon completion, a 
summary report is produced indicating that the job was terminated. 

12.3.4. Performing a List Operation 
The list function consists of the following three screens: 


¢ Screen 1 (HUOOBIL) is an informational screen telling you that the interactive 
job you selected has been initiated. 


¢ Screen 2 (HU35) asks you for the input device type. 


¢ Screen 3 (HU36 or HU37) asks you for your input volume serial number(s) or 
group identity and the file name. 


UP-8841 Rev. 4 12-21 





Disk Dump/Restore Routine (DMPRST) 








Screen 1 (HUOOBIL): Informational Message 


HU@@B1@2 
A CONVERSATIONAL JOB (HUSLST) TO LIST THE NAMES OF FILES DUMPED 
TO A SEQUENTIAL DISK FILE, A TAPE, OR A DISKETTE FROM DISK(S) 
WILL BE INITIATED IN YOUR BEHALF. YOU MUST BE IN SYSTEM MODE 


FOR THE JOB TO BE SCHEDULED. IF YOU ENTERED HAROWARE UTILITIES 
THROUGH THE HU COMMAND, YOU WILL BE IN SYSTEM MODE AFTER TRANS- 
MITTING. IF YOU ENTERED THROUGH THE MENU COMMAND YOU ARE 
RESPONSIBLE FOR GOING INTO SYSTEM MODE. 

weeke TRANSMIT TO CONTINUE ***** 





This is an informational message screen. Read it and press XMIT key to continue. 


Screen 2 (HU35): List Input Device Information 


LIST INPUT DEVICE INFORMATION 


ENTER i..°UT DEVICE TYPE (TAPE, DSKT OR SPECIFIC DISK TYPE): 


wewkiee SUNCTION KEYS: F1I3=HELP, F1I4=EXIT HELP ******* 





Enter the type of input device. If you specify tape, Screen 3 is HU36; otherwise, 
Screen 3 is HU37. 


Screen 3 (HU36): List Input Volume Information (Tape) 


LIST INPUT VOLUME INFORMATION 


ENTER INPUT VOLUME SERIAL NUMBER(S) 


wewkewee FUNCTION KEYS: F13=HELP, FI4=EXIT HELP 9 ******** 





For tape input, enter the volume serial number(s). 
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®& Screen 3 (HU37}: List Input Volume Information (Diskette or Disk) 


LIST INPUT VOLUME INFORMATION HU37 


ENTER INPUT VOLUME SERIAL NUMBER(S) OR IDENTITY OF GROUP OF VOLUMES: 


ENTER Y IF THIS IS THE IDENTITY OF A GROUP OF VOLUMES: NW 


ENTER FILE NAME: 


aueeenee FUNCTION KEYS: F13=HELP, FI4=EXIT HELP SEARNTER, 





12.4. Executing DMPRST in Volume Mode (Batch 
Environment) 


@ As shown in Table 12-1, you can execute DMPRST in either volume or file mode. By 
executing DMPRST in volume mode, you can back up an entire disk volume or a 
truncated portion of that volume. On the other hand, if you want to create backups of 
individual files on your disk, you can run the DMPRST routine in file mode. Both 
modes permit you to choose a disk, tape, or data set label diskette as your backup 
medium. In 12.4, we will discuss volume mode while in 12.5 we will discuss file mode. 


Since a printer is not automatically assigned in this operation as is the case in the 
interactive environment, you should assign one in your control stream. DMPRST will 
then give a listing of the // PARAM statements and all error messages. If no printer is 
assigned, only critical error messages will be displayed on your workstation screen. 


Table 12-2 summarizes the // PARAM statements along with the appropriate LFD 
names and the type of operation that will be performed. A complete description of 
these statements is provided in 12.4.1 through 12.4.5. 
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Table 12-2. Volume Mode // PARAM Statements 


Type of Operation // PARAM Statement LFD Name 


Copy disk to disk // PARAM IN=DISC DISCIN 
// PARAM OUT=DISC DISCOT 
// PARAM END=LAST 


Dump disk to MIRAM disk file // PARAM IN=DISC DISCIN 
// PARAM OUT=SEQD SEQDOT, INIT 
// PARAM END=LAST 


Dump disk to tape // PARAM IN=DISC DISCIN 
, // PARAM OUT=TAPE TAPEOT 
// PARAM END=LAST 


Dump disk to streaming tape // PARAM IN=DISC DISCIN 
// PARAM OUT=TAPE,SLOW TAPEOT 
// PARAM END=LAST 


Dump disk to diskette // PARAM IN=DISC DISCIN 
// PARAM OUT=SEQD SEQDOT, INIT 
// PARAM END=LAST 











Restore tape to disk // PARAM IN=TAPE TAPEIN 
// PARAM OUT=DISC DISCOT 

Restore streaming tape to disk // PARAM IN=TAPE,SLOW TAPEIN 
// PARAM OUT=DISC DISCOT 
// PARAM END=LAST 

Restore diskette to disk // PARAM IN=SEQD SEQDIN 
// PARAM OUT=DISC DISCOT 

Restore MIRAM disk file to disk // PARAM IN=SEQD SEQDIN 
// PARAM OUT=DISC DISCOT 

Copy tape to tape // PARAM IN=TAPE TAPEIN 
// PARAM OUT=TAPE TAPEOT 


Copy diskette to diskette // PARAM IN=SEQD SEQDIN 
// PARAM OUT=SEQD SEQDOT 


Check file expiration date // PARAM NOEXPCK 


Restart processing for dump/ // PARAM RESTART 
restore to tape or diskette 
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12.4.1. Performing a Disk Copy Operation in Volume Mode 


During a disk copy operation, you are copying the contents of a disk to another disk of 
the same type. Since the input and the output in a disk copy operation are always a 
disk, specify // PARAM IN=DISC as your input parameter and // PARAM OUT=DISC 
as your output parameter. In addition, specify DISCIN on the input // LFD statement 
and DISCOT on the output // LFD statement as file names. 


You can control the termination of the copy operation by specifying the // PARAM 
END statement. The // PARAM END=ccc statement terminates the copy operation 
after a specific cylinder (ccc) is copied. By specifying // PARAM END=LAST, you 
terminate the copy operation after the last allocated cylinder has been copied. You 
should specify a // PARAM END statement. If you omit it, the entire contents of the 
input disk is copied to the output disk, even if only a few cylinders contain user data. 


Note: If you use the // PARAM END=ccc statement, ccc must be specified in decimal. 


The following two examples are typical job streams used to perform a disk copy 
operation. In Example 1, the disk volume DISKO1 is copied to the backup disk volume 
DISKO2. Also, the copy operation is terminated after the last allocated cylinder has 
been copied. In Example 2, the resident volume OS3RES is copied to the backup 
volume RESBAK. The copy operation is terminated after the last allocated cylinder 
has been copied. Note that, even though a different disk type is used in each example, 
the // PARAM IN, // PARAM OUT, and // LFD names are always the same. 


Example 1: Disk Volume Copy Operation Using 8419 Disks 


// JOB OSKCOPY1 

// DVC 28 // LFD PRNTR 

// DVC 58 // VOL DISK@1 // LFD DISCIN 
// DVC 51 // VOL DISK@2 // LFD DISCOT 
// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=DISC 

// PARAM END=LAST 

/& 

// FIN 


Example 2: Disk Volume Copy Operation Using 8417 Disks 


// SOB DSKCOPY2 

// OVC 20 // LFD PRNTR 

// OVC 5@ // VOL OS3RES // LFD DISCIN 
// DVC 51 // VOL RESBAK // LFD DISCOT 
// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=DISC 

// PARAM END=LAST 

7% 

// FIN 
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12.4.2. Performing a Dump Operation in Volume Mode 


12-26 





The dump operation enables you to dump a disk or portion of a disk to tape, diskette, 
or a MIRAM file on a disk of a different type from the original. You may use any tape, 
data set label diskette, or a MIRAM disk file as a backup in a dump operation. 
However, the parameters specified in your control stream depend upon the devices 
being used. 


In a dump operation, the input is always from disk. Therefore, specify // PARAM 
IN=DISC as your input parameter and DISCIN as the file name on the // LFD job 
control statement of the input disk. 


If you only want to dump a portion of a disk, include a // PARAM END=ccc statement 
in your job control stream. The // PARAM END=ccc statement terminates the dump 
operation after a specific cylinder (ccc) has been dumped. If you specify // PARAM 
END=LAST, the dump operation terminates after the last allocated cylinder has been 
dumped. 


If you omit the // PARAM END parameter, the entire contents of the input disk is 
dumped to the output (including test pattern data written by the disk prep routine), 
even if only a few cylinders include user data. 


The output in a dump operation may be a tape, data set label diskette, or a MIRAM 
file on a disk of a different type than the original. Your output parameter, however, 
depends on your output medium. Remember, the device you select for output must 
first be prepped. 





Dumping to Tape in Volume Mode 


When using magnetic tape as the output, specify // PARAM OUT=TAPE as your 
output parameter and TAPEOT as the file name on your tape // LFD job control 
statement. These same parameter specifications are applicable if your output tape is a 
streaming tape operating in default (100 ips) mode. If, however, you want the 
streaming tape to operate in slow (25 ips) mode, then you must include the SLOW 
parameter in the // PARAM statement (// PARAM OUT=TAPE,SLOW). Table 12-2 
(see 12.4) lists the formats for the // PARAM statement when executing DMPRST in 
volume mode (batch). When dumping to a streaming tape, it is recommended that 
your system be dedicated to dump restore to ensure the streaming mode operation. 


When using more than one tape as output, you can assign them in your control stream 
in one of two ways. One way is to use a single device assignment set (DVC-LFD 
sequence) having a file name of TAPEOT. Include one // VOL statement listing the 
volume serial numbers of all output tapes (see Example 1). 


Another way is to supply a separate device assignment set for each output tape. Here, 
a separate device is assigned for each tape volume. Again, the file name on your tape 
//LFD statement is TAPEOT. However, 01 through 99 are attached to each tape file 
name, following the first one (i.e., // LFD TAPEOT01) (see Example 2). 
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@ The first record written to your magnetic tape is called the control record. The control 
record contains the following information in the order shown: 
Bytes Contents 
0-1 Control record ID X‘COCO’ 
2-5 System time (packed decimal) 
6-9 ' System data (packed decimal) 
10-15 Volume serial number of dumped disk pack 
16-17 Unused 
18-21 Device type of dumped disk pack 
22 Device type of tape 
23 Tape channel number 
24-25 Unused 
26 XP - shows file processing 
@ 27-30 Volume table of contents of dumped disk if file processing 
| 31-79 Unused 


The following two examples show multivolume dump operations using a magnetic 
tape: 


Example 1: Multivolume Dump Using a Single Device Assignment Set for All Output Tapes 


// 3OB TAPDUMP 1 

// DVC 20 // LFD PRNTR 

// OVC 5@ // VOL OS3RES // LFD DISCIN 

// DVC 98 // VOL SP0366,SP0367,SP0368 // LFD TAPEOT 
// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=TAPE 

/& 

// FIN 


The disk volume OS3RES is dumped to tape volumes SPO366, SPO367, and SPO368. 
Here, a single device assignment set (DVC-LFD sequence) assigns all three output 
tapes. Each tape volume is mounted separately on the same tape drive. 
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Example 2: Multivolume Dump Using a Separate Device Assignment Set for Each Output Tape © 


// JOB TAPDUMP2 

// OVC 20 // LFD PRNTR 

// OVC 5@ // VOL OS3SRES // LFD DISCIN 
// OVC 98 // VOL SP0366 // LFD TAPEOT 
// DVC 91 // VOL SPO367 // LFD TAPEOT@1 
// DVC 92 // VOL SPO368 // LFD TAPEOT@2 
// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=TAPE 

/% 

// FIN 


The disk volume OS3RES is dumped to tape volumes SPO366, SPO367, and SPO368. 
Here, each tape volume is assigned via an individual device assignment set and the 
tape volumes are mounted simultaneously on separate tape drives. 


Dumping to Diskettes in Volume Mode 
If you are using a diskette as output, specify // PARAM OUT=SEQD as your output 


parameter. DMPRST stores its control information and the data from the original disk 
in a MIRAM file on the backup diskettes. 





When you dump files to a diskette, must be prepped as a data set label diskette with a 
block size of 256 or 128 bytes. You should also use the default FDATA=Y prep option 
to allocate the entire diskette as one file called DATA. Remember to use the name 
DATA in the LBL statement of your DMPRST job control stream. 


If you want to use a file name other than DATA, you must prep the diskette using the 
FDATAEN prep option. Then you must allocate this MIRAM file in blocks. You do this 
through the interactive services ALLOCATE command or by using the // EXT job 
control statement with the BLK parameter. To determine the number of blocks 
required in the diskette file, use the following formula: 


number of cylinders number of surfaces track capacity _ total number of bytes 
being dumped from disk (tracks) per disk (bytes per track) being dumped from disk 


total number of bytes . diskette block size _ number of diskette 
being dumped from disk © (bytes per block) blocks required 


To determine the number of cylinders being dumped from disk, use an interactive 
services VTOC command. The number of surfaces per disk and the track capacity 
depend on the disk type. The diskette block size must be 256 or 128 bytes. For these 
values, see the Consolidated Data Management Programming Guide (UP-9978). 


Since most dump operations require multiple diskettes, it’s much easier to use the 
default name DATA rather than change the name on each diskette. 
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The file name on your diskette // LFD statements is SEQDOT, INIT. Unlike the file 
name specification for tape, only a single device assignment set (DVC-LFD sequence) 
may be provided, even if you are using more than one diskette. You include the INIT 
parameter in the LFD statement to initialize the diskette so DMPRST can dump to it. 
Remember, however, that you must not include the INIT parameter when performing 
the restore operation from that diskette. 


All volumes must be listed on // VOL statements unless // VOL SCRATCH is used. For 
more information on the // VOL SCRATCH statement, see the Job Control Language 
Programming Guide (UP-9986). 


The following example shows a typical job stream for a multivolume dump operation 
using diskettes: 


// JOB DSKTDMP1 

// DVC 20 // LFD PRNTR 

// DVC 5@ // VOL OS3RES // LFD DISCIN 

// OVC 13@ // VOL DSKT@1,DSKT@2, DSKT@3, DSKT@4 
// LBL DATA // LFD SEQDOT,, INIT 

// EXEC DMPRST : 

// PARAM IN=DISC 

// PARAM OUT=SEQD 

1% 

// FIN 


The disk volume OS3RES is dumped to a MIRAM file named DATA on diskette 
volumes DSKT01, DSKT02, DSKT03, and DSKT04. The MIRAM file DATA was 
allocated to diskettes as part of the prep procedure performed prior to the job run. 
Since a MIRAM file is required when dumping to diskette, the diskette must be 
prepped in the data set label mode. 


Dumping to a MIRAM Disk File in Volume Mode 


When you dump to a MIRAM disk file, your output disk may be a different type from 
the original, e.g., dumping from an 8417 disk to an 8419 disk. Before performing the 
dump operation, you must allocate a MIRAM file on the output disk for use by 
DMPRST. 


Note: The 8417 fixed-head disk can only be dumped in file mode. 


If one output disk is sufficient, allocate the MIRAM file by including the necessary job 
control statements in your DMPRST job control stream. However, for more than one 
output disk, you should allocate the MIRAM file in a separate job before running your 
DMPRST job. For more information on allocating files, see the Job Control Language 
Programming Guide (UP-9986). 


Specify // PARAM OUT=SEQD as your output parameter and the file name on your 
output disk // LFD job control statement as SEQDOT, INIT. As in the case of a 
diskette, only one device assignment set (DVC-LFD sequence) may be used. 
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You include the INIT parameter in the LFD statement to initialize the disk so 
DMPRST can dump to it. Remember, however, that you must not include the INIT 
parameter when performing the restore operation from that disk. 


The following examples show dump operations using disks. 
Example 1: Single-Volume Dump to Disk 


// JOB DSKDUMP1 

// DVC 20 // LFD PRNTR 
// DVC 5@ // VOL DISKO1 // LFD DISCIN 
// ove 51 

// NOL BKUPO1 

// EXT 'MI,C, ,CYL, 800 
// UBL PAYBACKUP 

// LED SEQDOT,, INIT 

// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=SEQD 

// PARAM END=LAST 

/& 

// FIN 


The 8417 disk volume, DISKO1, is dumped to the PAYBACKUP file on the 8419 disk 
volume, BKUP01. The dumped contents of the original volume is stored on the backup 
volume in a MIRAM file. Therefore, a MIRAM file is allocated for the PAYBACKUP 
file. Since only one backup volume is used, this file is allocated by specifying the 
necessary job control statements in the DMPRST job itself. 





Example 2: Multivolume Dump to Disk 


// JOB DSKDUMP2 

// DVC 20 // LFD PRNTR 

// OVC 5@ // VOL OS3RES // LFD DISCIN 
Jf OVC 51 // VOL BKRES1, BKRES2 

// LBL PACKSAVE // LFD SEQDOT,, INIT 
// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=SEQD 

/& 

// FIN 


In this example, an OS/3 resident volume is dumped to two 8419 disk volumes, 
BKRES1 and BKRES2. Here, as in Example 1, the dumped contents of the original 
disk are stored in a MIRAM file on the backup volume. Therefore, a MIRAM file 
named PACKSAVES is allocated on each backup volume. Since two backup volumes 
are used, the MIRAM files are allocated in separate jobs prior to the execution of the 
DMPRST job. Note that a single device assignment set is used for the backup volumes. 
(Only one disk drive is permitted; multimount disks are not allowed.) 
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12.4.3. Performing a Restore Operation in Volume Mode 


When you perform a dump operation, the backup volume that is created is stored in a 
MIRAM file. Therefore, you cannot use the dumped backup volume on your system if 
your original data is lost. Before actually using any backup data on your system, you 
must restore it to the original disk or a disk of the same type as the original. 


In a restore operation, the output is always a disk. Therefore, you should always 
specify // PARAM OUT=DISC as your output parameter and DISCOT as the file name 
on your output disk // LFD job control statement. 


The input in a restore operation may be tape, data set label diskette, or a MIRAM disk 
file of a different type from the original. However, the input parameter used depends 
on your input medium. 


Restoring from Tape in Volume Mode 


When using magnetic tape as the input, specify // PARAM IN=TAPE as your input 
parameter and TAPEIN as the file name on your tape // LFD job control statement. 
These same parameter specifications are applicable if your input tape is a streaming 
tape operating in the default (100 ips) mode. If, however, you want the streaming tape 
to operate in the slow (25 ips) mode, then you must include the SLOW parameter in 
the // PARAM statement (// PARAM IN=TAPE,SLOW). Table 12-2 lists the formats for 
the // PARAM statement when executing DMPRST in volume mode (batch). It is 
recommended, when restoring from a streaming tape, that your system be dedicated 
to dump restore to ensure the streaming mode operation. 


When using more than one tape as input, you can assign them in your control stream 
in one of two ways. One way is to use a single device assignment set (DVC-LFD 
sequence) having a file name of TAPEIN. Included in this set are // VOL statements 
listing the volume serial numbers of the restore operation input tapes. 


Another way is to supply a separate device assignment set for each tape in your job. 
Here, a separate device is assigned for each tape volume. Again, the file name (// LFD) 
is TAPEIN. However, the numbers 01 through 99 are attached to each tape file name, 
following the first one (i.e., // LFD TAPEINO1). 


Note: If you perform a dump operation using separate device assignment sets and 
then restore using a single device assignment set, you'll receive an error message 
from data management. The method of assigning tapes used in the dump 
operation should also be used in the related restore operation. 
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The following two examples show restore operations using magnetic tape: 
Example 1: Multivolume Restore Using a Single Device Assignment Set for Tape 


// JOB TAPERSTR1 

// DVC 28 // LFD PRNTR 

// DVC 98 // VOL SP0366,SP0367,SP0368 // LFD TAPEIN 
// DVC 58 // VOL OS3RES // LFD DISCOT 

// EXEC DMPRST 

// PARAM IN=TAPE 

// PARAM OUT=DISC 

/& 

// FIN 


The tape volumes SPO366, SPO367, and SPO368, which contain the backup volume 
OS3RES, are restored to the original disk. Here, a single device assignment set 
assigns the tapes in this control stream. Each tape volume is mounted separately on 
the same tape drive. 


Example 2: Multivolume Restore Using Separate Device Assignment Sets for Tape 


// JOB TAPERSTR2 

// DVC 20 // LFD PRNTR 

// DVC 98 // VOL SPO366 // LFD TAPEIN 
// OVC 91 // VOL SP0367 // LFD TAPEINO1 
// OVC 92 // VOL SPO368 // LFD TAPEIN@2 
// OVC 58 // VOL OS3RES // LFD DISCOT 

// EXEC DMPRST 

// PARAM IN=TAPE 

// PARAM OUT=DISC 

/& 

// FIN 


~ 


The tape volumes SPO366, SPO367, and SPO368, which contain the backup volume 

OS3RES, are restored to the original disk. Here, each tape volume is assigned via an 
individual device assignment set. The tape volumes are mounted simultaneously on 

separate tape drives. 


Restoring from Diskettes in Volume Mode 
If your input is a diskette, specify // PARAM IN=SEQD as your input parameter, and 
SEQDIN as the file name on your diskette // LFD job control statement. You may only 


specify one device assignment set (DVC-LFD sequence) when multivolume diskettes 
are used. 
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The following example shows restore operations using diskettes: 


// JOB DSKTRST 

// DVC 28 // LFD PRNTR 

// DVC 138 // VOL DSKT@1,DSKT@2,DSKT@3,DSKT4 
// LBL DATA // LFOD SEQDIN 

// DVC 50 // VOL OS3RES // LFD DISCOT 

// EXEC DMPRST 

// PARAM IN=SEQD 

// PARAM OUT=DISC 

sk 

// FIN 


The diskettes created by the dump operation in 12.4.2 are restored to the original disk 
volume, OS3RES. Since the data on the diskettes is stored on a MIRAM file named 
DATA, the LBL name DATA must be included in the diskette device assignment set. 


Restoring from a MIRAM Disk File in Volume Mode 


Since the input in a restore operation is from a MIRAM disk file, specify // PARAM 
IN=SEQD as your input parameter and SEQDIN as the file name on your input disk 
// LFD job control statement. 


Include the name of the input disk MIRAM file in your control stream. This is the 
same name that was assigned for the related dump operation. Remember, only a 
single device assignment set may be used to assign your input disk volumes. 


The following two examples show restore operations using disk; 
Example 1: Single-Volume Restore from Disk 


// JOB DISKRST1 

// DVC 28 // LFD PRNTR 

// DVC 5@ // VOL BKUP®1 

// LBL PAYBACKUP // LFD SEQDIN 

// DVC 51 // VOL DISK®1 // LFD DISCOT 
// EXEC DMPRST 

// PARAM IN=SEQO 

// PARAM OUT=DISC 

/& 

// FIN 


This backup disk volume, BKUP01, which was created by the dump operation shown 
in Example 1 in “Dumping to a MIRAM File in Volume Mode” in 12.4.2, is restored to 
the original disk volume, DISK01. Since the backup data is stored in a MIRAM file 
named PAYBACKUP, the LBL name PAYBACKUP is included in the disk device 
assignment set. 


UP-8841 Rev. 4 12-33 





Disk Dump/Restore Routine (DMPRST) 


12.4.4. 
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Example 2: Multivolume Restore from Disk 


// JOB DISKRST2 

// DVC 20 // LFD PRNTR 

// OVC 5@ // VOL BKRES1,BKRES2 

// UBL PACKSAVE // LFD SEQDIN 

// OVC 51 // VOL D@QQ@1 // LFD DISCOT 
// EXEC DMPRST 

// PARAM IN=SEQD | 
// PARAM OUT=DISC 
/& 

// FIN 





The backup disk volumes, BKRES1 and BKRES2, which were created by the dump 
operation shown in Example 2 in “Dumping to a MIRAM Disk File in Volume Mode” 
in 12.4.2, are restored to the disk volume D00001. The disk-resident volume cannot be 
the output disk in a volume restore operation. Therefore, the restore is made to 
another disk of the same type (D00001) as the original. When the restore is complete, 
the volume serial number (VSN) on the output pack (D00001) will be OS3RES. 


The backup data is stored in a MIRAM file called PACKSAVE on the backup volumes. 
Therefore, the LBL name PACKSAVE must be included in the disk device assignment 
set. Note that a single device assignment set is used for the backup volumes. 





Performing a Tape Copy Operation in Volume Mode & 


In a tape copy operation, you are copying the contents of one tape to another. The tape 
being copied must be one that was created by a previous DMPRST operation in 
volume mode. The DMPRST routine will not copy a tape created in file mode. 
DMPRST cannot be used to copy multivolume tape files to tape. 


Input and output in a tape copy operation are always tapes. Therefore, // PARAM 
IN=TAPE and // PARAM OUT=TAPE must be specified along with the file names 
TAPEIN for input and TAPEOT for output. 


The following is an example of a typical job stream used to perform the tape copy 
operation: 


// S08 TAPECOPY 

// OVC 26 // LFD PRNTR 

// DVC 98 // VOL PAY@62 // LFD TAPEIN 
// DVC 91 // VOL PAY@@3 // LFD TAPEOT 
// EXEC DMPRST 

// PARAM IN=TAPE 

// PARAM OUT=TAPE 

/& 

// FIN 
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12.4.5. Performing a Diskette Copy Operation in Volume Mode 


In a diskette copy operation, you are copying the contents of one set of diskettes to 
another. The diskettes being copied must be a set that was created by a previous 
DMPRST operation in volume mode. 


Input and output in a diskette copy operation are always diskettes. Therefore, 
// PARAM IN=SEQD and // PARAM OUT=SEQD must be specified along with the file 
names SEQDIN for input and SEQDOT for output. 


The following is an example of a typical job stream used to perform the diskette copy 
operation: 


// SOB DSKTCOPY 

// DVC 20 // LFD PRNTR 

// OVC 13@ // VOL COPY@1,COPY@2, COPY@3 
// (BL DATA // LFD SEQDIN 

// DVC 131 // VOL COPY@A, COPYOB, COPY@C 
// LBL. DATA // LFD SEQDOT 

// EXEC DMPRST 

// PARAM IN=SEQD 

// PARAM OUT=SEQD 

/k 

// FIN 


@ The contents of the diskette set, COPY01, COPY02, COPY03, are copied to the 
diskette set COPYOA, COPYOB, COPYOC. Since the file DATA was allocated to each 
diskette during prep, the LBL name DATA must be supplied in each device 
assignment set. 


12.5. Executing DMPRST in File Mode (Batch Environment) 


You may execute DMPRST in the file mode to create backups of individual files on 
your disk or disks. Choose disk, tape, or data set label diskette as your backup, 
depending on which DMPRST procedure is used. Multidisk volumes can be dumped to 
a tape. In a single-disk volume environment, you can copy, dump, and restore an 
entire volume of active files. As in volume mode, you should assign a printer to list the 
/! PARAM and FILE statements and any error messages. 


Table 12-3 summarizes the // PARAM and FILE statements along with the 
appropriate LFD names and the type of operation that will be performed. A complete 
description of these statements is provided in 12.5.1 through 12.5.5. 
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Table 12-3. File Mode // PARAM and FILE Statements 


// PARAM Statement LFD Name 


Type of Operation 


Copy disk to disk 
Dump disk to MIRAM disk file 
Dump disk to tape 


Dump multiple disks to tape 


Dump disk to diskette 
Restore tape to disk 


Restore tape to multiple disks 


Restore diskette to disk 
Restore MIRAM disk file to disk 


Copy diskette to diskette 





// PARAM IN=DISC 
// PARAM OUT=DISC 
// PARAM TYPE=FILE 


// PARAM IN=DISC 
// PARAM OUT=SEQD 
// PARAM TYPE =FILE 


// PARAM IN=DISC 
// PARAM OUT=TAPE 
// PARAM TYPE=FILE 


// PARAM IN=DISC(D01,D02,...Dnn) 


// PARAM IN=DISC 
// PARAM OUT=SEQD 
// PARAM TYPE=FILE 


// PARAM IN=TAPE 
// PARAM OUT=DISC 
// PARAM TYPE=FILE 


// PARAM OUT=DISC(D01,D02,...Dnn) 


// PARAM IN=SEQD 
// PARAM OUT=DISC 
// PARAM TYPE=FILE 


// PARAM IN=SEQD 
// PARAM OUT=DISC 
// PARAM TYPE=FILE 


// PARAM IN=SEQD 
// PARAM OUT=SEQD 
// PARAM TYPE =FILE 





DISCIN 
DISCOT 


DISCIN 
SEQDOT, INIT 


DISCIN 
TAPEOT 


DISCINO1 
DISCINO2 
DISCINnn 
DISCIN 


SEQDOT, INIT 


TAPEIN 
DISCOT 


DISCOTO1 
DISCOTO2 
DISCOTnn 
SEQDIN 
DISCOT 


SEQDIN 
DISCOT 


SEQDIN 
SEQDOT 


continued 
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Table 12-3. File Mode // PARAM and FILE Statements (cont.) 


Type of Operation // PARAM Statement LFD Name 
Process only active permanent files // PARAM TYPE=FILE,ALL 

Restore from any diskette or tape // PARAM TYPE=FILE,ANY 

volume 


Avoid wait for file to be available 7/ PARAM TYPE=FILE,NOWAIT 
Suppress file expiration date check // PARAM NOEXPCK 


Restart processing for dump/restore // PARAM RESTART 
to tape or diskette 


12.5.1. Performing a Disk Copy Operation in File Mode 


When performing a disk copy operation in file mode, you copy the contents of 
individual files on a disk to another disk of the same type. 


Input and output in a disk copy operation are always disks. Therefore, specify 

// PARAM IN=DISC as your input parameter and // PARAM OUT=DISC as your 
@ output parameter. In addition, you must specify the file names DISCIN on the input 

//LFD statement and DISCOT on the output // LFD statement. 


Since you are copying files, specify // PARAM TYPE=FILE to inform DMPRST that 
file, rather than volume, processing is performed. 


Associated with the // PARAM TYPE=FILE parameter are FILE statements. By 
including these statements as embedded data in your control stream, you can name 
which files you want copied by either file name or file prefix. 


The FILE statements are free-formatted, meaning that the first character may start 
anywhere. However, you must place a blank character between the FILE statement 
and the first operand to act as a delimiter. If you specify a file name containing 
embedded blanks, enclose it in quotation marks (i.e., FILE “PAY BACKUP”). 


If you want to copy an entire volume of active permanent files, use the FILE,ALL 
statement. By active permanent files, we mean all files that have entries in the VTOC 
and are not job temporary files (new libraries and scratch files). Any files deleted, but 
not physically removed, are not copied. The VTOC is not copied. (In volume mode, 
everything is copied.) 
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The following example shows a disk copy operation in file mode: 


// JOB OFILCPY 

// DVC 20 // LFD PRNTR 

// DVC 58 // VOL DISK@1 // LFD DISCIN 
// DVC 51 // VOL DISK@2 // LFD DISCOT 
// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=DISC 

// PARAM TYPE=FILE 


/$ 
FILE MONEY 
FILE INTEREST 
FILE BILLS 
FILE.P BANK 

/* 

1% 

// FIN 


The files MONEY, INTEREST, and BILLS and all files with the prefix of BANK on 
disk volume DISKO1 are copied to disk volume DISK02. Note that the FILE 
statements are included as embedded data in the control stream. 


The following example shows a disk copy operation in file mode copying the entire 
volume of active files: 





// JOB COPYALL 

// OVC 20 // LFD PRNTR 

// DVC 5@ // VOL DISK@1 // LFD DISCIN 
// DVC 51 // VOL DISK@2 // LFD DISCOT 
// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=DISC 

// PARAM TYPE=FILE,ALL 

/& 

// FIN 


Notes: 


1. Job temporary files (run libraries and scratch files) are not processed in this file 
mode. 


2. This file mode must be used when copying the entire contents from or to an 8417 
disk with fixed-head assembly because volume mode processing does not support 
fixed-head assembly processing. 
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Before DMPRST processes any files, it locks them. Therefore, if you are dumping or 
restoring a file currently being used in the system, DMPRST waits until the file is 
available before processing it. You can avoid this delay by specifying the NOWAIT 
parameter on the FILE statement. DMPRST, upon detecting NOWAIT, skips 
processing any of the unavailable files and goes to the next available file. All files 
skipped are listed on the printer so you can process them later. 


// JOB COPYALL 
// DVC 20 // LFD PRNTR 
// OVC 50 // VOL DISK@1 //.LFD DISCIN 
// OVC 51 // VOL DISK@2 // LFD DISCOT 
// EXEC DMPRST 
- // PARAM IN=DISC 
// PARAM OUT=DISC 
// PARAM TYPE=FILE,NOWAIT 


/$ 
FILE CREDIT 
FILE ASSETS 
FILE INVENTORY 

/* 

/& 

// FIN 


Performing a Dump Operation in File Mode 


The dump operation enables you to copy individual files or an entire volume of active 
permanent files from a disk to tape, diskette, or a MIRAM file on a disk of a different 
type from the original. You may use any tape, data set label diskette, or a MIRAM 
disk file as a backup. However, the parameters specified in your control stream 
depend on which devices you are using. 


In a dump operation, the input is always from disk. (Multiple disks can be dumped to 
tape, as described later in this subsection.) Therefore, specify // PARAM IN=DISC as 
your input parameter, and DISCIN as the file name on your input disk // LFD job 
control statement. 


When performing a dump operation in file mode, you dump individual files. To inform 
DMPRST that you are dumping files rather than an entire volume, include the 
// PARAM TYPE=FILE parameter in your control stream. 


Associated with the // PARAM TYPE=FILE statement are FILE statements. You use 
these statements to specify either the file name or the file prefix (up to 16 bytes) of the 
files you want dumped and you include them in your control stream as embedded 
data. 


The FILE statements are free-formatted, meaning that the first character may start 
anywhere. However, you must place a blank character between the FILE statement 
and the first operand to act as a delimiter. If you specify a file name containing 
embedded blanks, enclose it in quotation marks (i.e., FILE “PAY BACKUP”). 
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Dumping a Single Disk to Tape in File Mode 


If you are using magnetic tape as output, specify // PARAM OUT=TAPE as your 
output parameter, and TAPEOT as the file name on your taxe’s // LFD job control 
statement. When using more than one tape as output, you can assign them in your 
control stream in one of the following ways: 


1. Usea single device assignment set (DVC-LFD sequence) having a file name of 
TAPEOT. Included in this set are // VOL statements listing the volume serial 
numbers of the backup tapes in the DMPRST job. 


2. Supply a separate device assignment set for each tape in your job. Here, a 
separate device is assigned for each tape volume. Again, the file name is 
TAPEOT; however, the numbers 01 through 99 are attached to each tape file 
name, following the first one (i.e., // TAPEOT01). 


Since you are executing DMPRST in file mode, include the // PARAM TYPE=FILE 
parameter in your job stream. 


Files must be restored in the same order as they were dumped. Therefore, you should 
keep a record of the file order. The simplest way is to save the listings from your dump 
operations. 


The following examples show file dump operations using magnetic tape. 





Example 1: Multifile Dump to a Single-Volume Tape 


// JOB TFILDMP1 

// OVC 20 // LFD PRNTR 

ff OVC 5@ // VOL DISK@1 // LFD DISCIN 
// DVC 98 // VOL PAY@@2 // LFD TAPEOT 
// EXEC OMPRST 

// PARAM IN=DISC 

// PARAM OUT=TAPE 

// PARAM TYPE=FILE 


/$ 
FILE CREDIT 
FILE ASSETS 
FILE.P HIST 

/* 

1% 

// FIN 


The disk files CREDIT and ASSETS and all files with the prefix HIST on volume 
DISKO1 are dumped to tape volume PAY002. 
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Example 2: Muttifile Dump to Multivolume Tapes Using a Single Device Assignment Set 


// JOB TFILDMP2 

// DVC 20 // LFD PRNTR 

// DVC 5@ // VOL MYPACK // LFD DISCIN 

// DVC 98 // VOL BACK®1,BACK@2,BACK®3, BACK04 
// LFD TAPEOT 

// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=TAPE 

// PARAM TYPE=FILE 


/$ 
FILE RPGII 
FILE MYCOBOLMASTER 
FILE PROCFILE 
FILE '*PAY BACKUP'' 
/* 
/& 
// FIN 


The disk files RPGII, MYCOBOLMASTER, PROCFILE, and PAY BACKUP are 
dumped from MYPACK to tape volumes BACK01, BACK02, BACKO3, and BACK04. 
Here, a single device assignment set (DVC-LFD sequence) is used to assign the tapes. 
Each tape volume is mounted separately on the same drive. Note that even though 
you are accessing files on disk, there is no // LBL name in the control stream. Since 
DMPRST doesn’t use the data management facility to search for your files, no // LBL 
statement is needed. Also, the name on the fourth FILE statement, “PAY BACKUP”, 
is enclosed in double quotes because of the embedded blank. 


Example 3: Multifile Dump to Multivolume Tapes Using Separate Device Assignment Sets 
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// 3OB TFELDMPS 

// OVC 20 // LFD PRNTR 

// DVC 5@ // VOL MYPACK // LFD DISCIN 
// DVC 98 // VOL BACK®1 // LFD TAPEOT 
// DVC 91 // VOL BACK@2 // LFD TAPEOT@1 
// OVC 92 // VOL BACK@3 // LFD TAPEOT@2 
// DVC 93 // VOL BACK@4 // LFD TAPEOT@3 
// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=TAPE 

// PARAM TYPE=FILE 


/$ 
FILE RPGII 
FILE MYCOBOLMASTER 
FILE PROCFILE — 
FILE '*PAY BACKUP! 
/* 
/& 
// FIN 
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This job is the same as the job performed in Example 2. Here, however, the tape 
volumes are assigned using separate device assignment sets. The volumes are 
mounted simultaneously on separate tape drives. 


Example 4: Entire Volume Dump of Active Permanent Files to Multivolume Tapes Using a Single 
Device Assignment Set 


// JOB DUMPALL 

// OVC 28 // LFD PRNTR 

// DVC 58 // VOL MYPACK // LFD DISCIN 
// DVC 98 // VOL BACKO1,BACK@2 
// LFD TAPEOT 

// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=TAPE 

// PARAM TYPE=FILE,ALL 

1% 

// FIN 


All active permanent files (entries in the VIOC) are dumped. 


Dumping Multiple Disks to Tape in File Mode 


If you are performing a multivolume dump to tape, all the volumes must be online on 
drives of the same disk type. Use the LFD names DISCINO1, DISCIN02,...DISCINnn 
for the disks. The input parameter is // PARAM IN=DISC(D01,D02,...Drn), where the 
numerics of the Dnn definitions correlate with those in the // LFD statements. The 
numerics need not be contiguous. The value of nn must be a two-digit number from 01 
to 16. 





The ALL specification cannot be used on the TYPE=FILE statement for a 
multidisk volume dump. 


Note: Tapes created with multidisk volume inputs cannot be restored by DMPRST on 
releases prior to Release 12.0 or by any release of SU@RST. 


The following statements would be required to dump files from three disk volumes 
(DISCAA, DISCBB, and DISCCC): 


// OVC 58 // VOL DISCAA // LFD DISCIN@1 


// OVC 51 // VOL DISCBB // LFD DISCIN@2 
// OVC 52 // VOL DISCCC // LFD DISCIN@3 


// PARAM IN=DISC(D01,D02,083) 
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Associated with each Dnn statement are DISC data statements. One of them must 
precede any FILE statements associated with that disk. Thus, the JCL to dump files 
from three disks would appear as follows: 


// JOB MULTIDUMP 
// OVC 20 // LFD PRNTR 
// OVC 5@ // VOL DISCAA // LFD DISCING@1 
// DVC 51 // VOL DISCBB // LFD DISCIN@2 
// DVC 52 // VOL DISCCC // LFD DISCINGS 
// DVC 98 // VOL TAPE@@ // LFD TAPEOT 
// EXEC DMPRST 
// PARAM IN=DISC(D@1,D02,003) 
// PARAM OUT=TAPE 
// PARAM TYPE=F ILE 
/$ 

DISC De1 

FILE PAYROLL 

DISC DO3 

FILE PAYROLL 

DISC De2 

FILE TAXES 

DISC D@3 

FILE PENSION 
/* 
/& 


Note: File PAYROLL is a multivolume file and two DISC and FILE statements are 
required to dump it in its entirety. 


Dumping to Diskette in File Mode 


If you are using a diskette as output, specify // PARAM OUT=SEQD as your output 
parameter. DMPRST stores its control information and any data from the original 
disk in a MIRAM file on the backup diskettes. You must prep each backup diskette as 
a data set label diskette with a record size of either 128 or 256 bytes. Since a default 
//LBL name of DATA is assigned when your diskette is prepped in the data set label 
mode, use the name DATA in your DMPRST control stream. 


A physical image of the files dumped from disk is stored in the MIRAM file DATA on 
diskette. Since the dumped files must be restored in the same order as they were 
dumped, you should keep a record of the file order. The simplest way to do this is to 
save the listings from your file dump operations. 


If you choose an output file other than DATA, first scratch the name DATA from your 
diskette and allocate a MIRAM file having the new name. Since most dump 
operations require multiple diskettes, it’s much easier to use the default name DATA 
than to change the name on each diskette. 
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The file name on your diskette’s // LFD statement is SEQDOT,,INIT. Unlike the file 
name specification for tape, only a single device assignment set (DVC-LFD sequence) 
may be provided, even if you are using more than one diskette. You include the INIT 
parameter in the LFD statement to initialize the diskette so DMPRST can dump to it. 
Remember, however, that you must not include the INIT parameter when performing 
the restore operation from that diskette. 


Since you are executing DMPRST in file mode, include the // PARAM TYPE=FILE 
parameter in your job stream. 


The following example shows a file dump to diskette: 


// JOB DSKTFIL1 

// DVC 2@ // LFD PRNTR 

// DVC 58 // VOL MYPACK // LFD DISCIN 

// DVC 138 // VOL SAVE@1,SAVE@2, SAVE@3, SAVEO4 
// LBL DATA // LFD SEQDOT, ,INIT 

// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=SEQD 

// PARAM TYPE=FILE 


/$ 
és FILE INVENTORY 
FILE PARTS 
FILE INVOICES 
/* 
/& 
// FIN 


The files INVENTORY, PARTS, and INVOICES on the disk volume MYPACK are 
dumped to the MIRAM file DATA on diskette. The DATA file is a multivolume file 
consisting of the volumes SAVE01, SAVE02, SAVE03, and SAVE04. 


Dumping to a MIRAM Disk File in File Mode 


When dumping to a MIRAM disk file, your output disk may be a different type from 
the original. For example, dumping from an 8417 disk to an 8419 disk. Before you can 
perform the dump operation, you must allocate a MIRAM file on the output disk. 


If a single output disk is sufficient, you may allocate the MIRAM file by including the 
necessary job control statements in your DMPRST control stream. However, for more 
than one output disk, allocate the MIRAM file in a separate job before running your 
DMPRST job. For more information on allocating files, see the Job Control Language 
Programming Guide (UP-9986). 


A physical image of the files dumped is stored in the MIRAM file you allocated on the 
output. Since dumped files are restored in the same order as they are dumped, you 
should keep a record of the file order. The simplest way to do this is to save the 
listings from your dump operations. 
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You must supply // PARAM OUT=SEQD as your output parameter and 

SEQDOT,, INIT as the file name on your output disks’ // LFD statement. As in the case 
of a diskette, only a single device assignment set (DVC-LFD sequence) can be used. 
You must list all volumes on the // VOL card or cards unless // VOL SCRATCH is used. 
For more information on the // VOL SCRATCH statement, see the Job Control 
Language Programming Guide (UP-9986). You include the INIT parameter in the 
LFD statement to initialize the disk so DMPRST can dump to it. Remember, however, 
that you must not include the INIT parameter when performing the restore operation 
from that disk. 


Since you are executing DMPRST in file mode, include the // PARAM TYPE=FILE 
parameter in your job stream. 


If you want to dump all the files on a disk, you may specify // PARAM 
TYPE=FILE,ALL as file mode parameter. This parameter causes all the files on the 
original disk to be dumped. You don’t need to include any FILE statements in your job 
stream when using the ALL option. 


The // PARAM TYPE=FILE,ALL parameter allows you to dump the entire contents of 
an 8417 fixed-head volume file by file. Use this parameter when you want to dump an 
8417 fixed-head disk volume, since this type disk can’t be dumped in volume mode. 


The following three examples show dump operations in file mode using disks: 
Example 1: Multifile Dump to Single-Volume Disk 


// JOB DFILDMP41 

// DVC 20 // LFD PRNTR 
// DVC 5@-// VOL D@@309 // LFD DISCIN 
// DVC 51 // VOL BACKUP 
// EXT MI,C, ,CYL, 100 
Jf LBL FILESAVE 

// LED SEQDOT, , INIT 

// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=SEQD 

// PARAM TYPE=FILE 


/$ 
FILE INTERSTPRG 
FILE MORTGAGEPRG 
FILE BALANCE 

/* 

7% 

// FIN 


The disk files INTERESTPRG, MORTGAGEPRG, and BALANCE are dumped to the 
MIRAM file, FILESAVE, on the disk volume BACKUP. FILESAVE is allocated on the 
output disk using the EXT statement. 
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Example 2: Multifile Dump to Multivolume Disk 


// JOB DFILDMP2 

// DVC 20 // LFD PRNTR 

// DVC 58 // VOL USA444 // LFD DISCIN 
// DVC 51 // VOL SAVE@1,SAVE@2 

// LBL RELEASED // LFD SEQDOT,, INIT 
// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=SEQD 

// PARAM TYPE=FILE 


/$ 
FILE ACCOUNTING 
FILE COBOLPROG 
FILE MARKETPROG 
FILE '*PRICE INDEX'' 
FILE TAXPROG 
FILE.P INV 

/* 

/& 

// FIN 


The files ACCOUNTING, COBOLPROG, MARKETPROG, PRICE INDEX, and 
TAXPROG, and all files prefixed with INV, are dumped to the MIRAM file 
(RELEASED) on two 8419 disks. RELEASED is allocated on disk volumes SAVEO1 
and SAVE02. Since two backup volumes are used in this job, the MIRAM file is 
allocated in separate jobs prior to the execution of the DMPRST job. Note that a single 
device assignment set is used for the backup volumes. 


Example 3: File-by-File Dump of an 8417 Fixed-Head Disk 


// JOB FIXDUMP3 

// DVC 2@ // LFD PRNTR 

// OVC 5@ // VOL FIXVOL // LFD DISCIN 
// DVC 51 // VOL FIX@01,F1X062 

// LBL DISKBACKUP // LFD SEQDOT,, INIT 
// EXEC DMPRST 

// PARAM IN=DISC 

// PARAM OUT=SEQD 

// PARAM TYPE=FILE,ALL 

/& 

// FIN 


All active permanent files on the 8417 fixed-head disk, FIXVOL, are dumped to disk 
volumes FIX001 and FIX002. Notice that no FILE statements are included because 
the // PARAM TYPE=FILE,ALL parameter is specified. This parameter must be used 
when dumping the entire contents of an 8417 fixed-head disk. 
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12.5.3. Performing a Restore Operation in File Mode 


When you dump files from a disk, the backup created is stored on a MIRAM file or on 
tape. Therefore, you cannot use the backup on your system in the event your original 
data is lost. Before actually using any backup data on your system, you must restore it 
to the original disk or a disk of the same type as the original. 


In a restore operation, the output is always a disk. Therefore, you must specify 
// PARAM OUT=DISC as your output parameter, and DISCOT as the file name on 
your disk’s // LFD statement. 


Since you are restoring files, include the // PARAM TYPE=FILE parameter in your job 
stream. This parameter informs DMPRST that file, rather than volume, processing is 
performed. 


Associated with the // PARAM TYPE=FILE parameter are FILE statements. Like the 
FILE statements used in file dump operations, they name the files you want 


processed. In a restore operation, however, they also allow you to rename files and 
specify the type of processing you want performed. 


The FILE statements are free-formatted, meaning that the first character may start 
anywhere. However, you must place a blank between the FILE statement and the first 
operand, and a comma between the operands to act as a delimiter. If you specify a file 
name containing embedded blanks, enclose it in double quotation marks. 

Two formats of the FILE statement are used in a restore operation: 

Format 1 


FILE old-name}, {ABS [,new-name) 


The old-name parameter specifies the name of the file you are restoring to disk. 
Format 2 


FILE.Pdprefix-name |, /ABS {,new-name) 


The prefix-name parameter specifies the prefix name of all the files to be restored. 
Regardless of the format, when restoring more than one file, you must restore the files 
in the order that they were dumped. 
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Using the Allocation Parameter to Control Restore Processing 


The second parameter in the FILE statement is the allocation parameter. This 
optional parameter enables you to control file processing. The allocation parameters 
are 


ass Locates a file on the same absolute extents. If a file cannot be allocated to 
the same extents, an error message is issued and DMPRST processes the 
next FILE statement. 


REL Relocates a file. If relocation to the same size file is not possible, a file large 
enough to hold the original file is allocated. If this is unsuccessful, an error 
message is issued and DMPRST processes the next FILE statement. 


toc Relocates a file and deletes all unassigned space for that file. LOG deletes 
only space that is not assigned to a partition control appendage (PCA). 


PRE Relocates a file in a space that was preallocated. This file space can be 
located anywhere on the disk. 


skp Suppresses the restore of a file. SKP is used only in diskette and tape restore 
operations. It must be used when restarting a tape restore; it is not required 
for a normal tape restore. 


You can only specify one allocation parameter in each FILE statement. Enter it after 
the old-name parameter, with a comma separating the two. 





When you want to perform standard restore processing, omit the allocation 
parameter. However, if you omit the allocation parameter and specify the new-name 
parameter, substitute a comma for the missing allocation parameter. 


During standard restore processing, DMPRST scratches a file if it already exists on 
the output disk and makes up to three attempts to reallocate it on the disk. 


When reallocating the file, DMPRST first attempts to allocate the same absolute 
extents occupied by the original file. If this is unsuccessful, the file relocation facility 
attempts to allocate the same size file at a different location. If this second try is also 
unsuccessful, the file relocation facility determines how much of the original space is 
actually assigned. It then tries to allocate a file large enough to hold the assigned 
space from the original file. If all three attempts fail, an error message is issued to the 
system console. 


Using the File Prefix Parameter 


The file prefix parameter gives you the capability to restore the first series of 
consecutive files having a certain prefix in the file name. Suppose you want to restore 
all files having the file name prefix of OLD. In addition, the restored files are to be 
located on the same absolute extents. The following example shows the restore 
operation using the prefix name and ABS parameters: 





12-48 UP-8841 Rev. 4 








Disk Dump/Restore (DMPRST) 


// LED UPDATE 
// OVC 20 // LFD PRNTR 
// DVC 13@ // VOL SAVE@1,SAVE@2, SAVEO3 
// LED SEQDIN 
// OVC 5@ // VOL NEVOL1,NEVOL2,NEVOL3 
// LFD DISCOT 
// EXEC DMPRST 
// PARAM IN=SEQD 
// PARAM OUT=DISC 
// PARAM TYPE=FILE 
/$ 
FILE.P OLD, ABS 
/* 
/& 
// FIN 


Note: When restoring files from tape, diskette, or sequential files on disk, the restore of 
files with the same prefix will terminate when the first file without that prefix is 
encountered on the input medium or at the end of the input file. The next file 
statement, if any, is then processed. 


Using the New-Name Parameter to Rename Files 


The third parameter in the FILE statement is the new-name parameter. You use it to 
change the name of a file being restored to disk. For example, suppose you want to 
restore the diskette file MYFILE to a file named PAYROLL on disk. In order to copy 
MYFILE to PAYROLL, you specify PAYROLL as the new-name parameter in the 
FILE statement with the old-name MYFILE. In this case, DMPRST first scratches 
any file having the name PAYROLL from the output disk. Next, DMPRST allocates a 
file large enough for MYFILE. The old file, MYFILE, bearing the new name 
PAYROLL, is then written to the allocated space on the output disk. 


The following example shows a restore operation using the new-name parameter: 


// JOB RENAME 

// DVC 20 // LFD PRNTR 

// DVC 13@ // VOL SAVE@1,SAVE@2, SAVEO3 
// LFD SEQDIN 

// DVC 58 // VOL BAKVOL // LFD OISCOT 
// EXEC DMPRST 

// PARAM IN=SEQD 

// PARAM OUT=DISC 

// PARAM TYPE=FILE 


/s 
FILE OLDNAME ,REL ,NEWNAME 
FILE OLDACCOUNTS, ,NEWACCOUNTS 
/* 
se 
// FIN 
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The files are restored to disk with the new file name specified by the new-name 
parameter. For the first file(OLDNAME), DMPRST scratches any file having the 
name NEWNAME from the output disk. DMPRST then allocates a file large enough 
for the file OLDNAME. The old file OLDNAME bearing the new file name 
NEWNAME is then written to the allocated space on the output disk. The same 
procedure is followed for the second FILE statement. Here, however, a comma is 
substituted for the missing allocation parameter. As in all restore operations, the files 
are restored in the same order they were dumped. 


Global File Allocation Parameters 


If you are restoring all files in a single-disk volume environment, you can specify a 
global allocation parameter (REL, LOG, PRE, and ABS) on the TYPE=FILE,ALL 
parameter and it will apply to all the files being restored. The function of these global 
specifications is the same as for the allocation parameters specified on a FILE 
statement (see “Using the Allocation Parameter to Control Restore Processing” earlier 
in this subsection). ; 


Restoring from Tape to a Single-Disk Volume in File Mode 


If you are using magnetic tape as input, specify // PARAM IN=TAPE as your input 
parameter, and TAPEIN as the file name on your tape’s // LFD statement. When using 
more than one tape as your input, you can assign them in your control stream in one of 
two ways. 


One way uses a single device assignment set (DVC-LFD sequence), which has a file 
name of TAPEIN. Included in this set are // VOL statements listing the volume serial 
numbers of the restore operation’s input tapes. 


Another way is to supply a separate device assignment set for each tape. Here, a 
separate device is assigned for each tape volume. Again, the file name on your // LFD 
statement is TAPEIN. However, the numbers 01 through 99 are attached to each tape 
file name, following the first one (i.e., FILE // LFD TAPEIN01). 


Since you are executing DMPRST in file mode, include // PARAM TYPE=FILE in your 
job stream. Also, supply the appropriate FILE statements as embedded data. 


Remember, files must be restored in the same order they were dumped. If you want to 
restore the entire volume of active files, use // PARAM TYPE=FILE,ALL. 


Notes: 


1. Tapes created in multidisk volume format must be restored using the JCL 
described in “Restoring Multiple Disks from Tape in File Mode” later in this 
subsection, even when restoring to only one of the disks. 


2. Ifyou perform a tape dump operation using separate device assignment sets and 
then restore using a single device assignment set, you will receive an error message 
from data management. The method of assigning tapes used in the dump 
operation should also be used in the related restore operation. 
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The following three examples show restore operations using magnetic tape. 


Example 1: Muttfile Restore from Single-Volume Tape File 


// JOB TFILRST1 

// DVC 20 // LFD PRNTR 

// DVC 98 // VOL PAY@@2 // LFD TAPEIN 
// OVC 5@ // VOL DISKG1 // LFD DISCOT 
// EXEC DMPRST 

// PARAM IN=TAPE 

// PARAM OUT=DISC 

// PARAM TYPE=FILE 


/$ 
FILE CREDIT,ABS 
FILE ASSETS,REL 
/* 
1k 
// FIN 


The files that were dumped to tape by the dump operation in Example 1 of “Dumping 
a single Disk to Tape in File Mode” in 12.5.2 are restored to the disk volume DISKO1. 
Note that the files are restored in the same order in which they were dumped. 


The first file, CREDIT, is restored to the same absolute extents that it originally 
occupied. This function is controlled by the allocation parameter, ABS. The second file, 
ASSETS, is restored to a different location on disk by the REL allocation parameter. 


Example 2: Multivolume Restore from Multivolume Tapes Using a Single Device Assignment Set 
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// JOB RENAME 

// DVC 20 

// LFD PRNTR 

// DVC 98 // VOL BACK@1,BACK92,BACKO3, BACKO4 
// LFD TAPEIN 

// DVC 58 // VOL MYPACK // LFD DISCOT 

// EXEC DMPRST 

// PARAM IN=TAPE 

// PARAM OUT=DISC 

// PARAM TYPE=FILE 


/$ 
FILE RPGII,REL,RPGII@2 
FILE MYCOBOLMASTER, ABS 
FILE PROCFILE, ,PROCFILE@2 
FILE ''PAY BACKUP'' 

/* 

/& 

// FIN 
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The files that were dumped in Example 2 of “Dumping a Single Disk to Tape in File 
Mode” in 12.5.2 are restored to the disk volume, MYPACK. Since the tapes were 
assigned in the dump operation using a single device assignment set, they are 
assigned in the restore operation in the same manner. 


Note that the files are restored in the same order in which they were dumped. The 
first FILE statement relocates the RPGII file to a new location on the output disk and 
changes the file name to RPGII02. The second FILE statement restores the file, 
MYCOBOLMASTER, to the same absolute extents it occupied on the original disk. 
The third FILE statement changes the name, PROCFILE, to PROCFILE02. Because 
no allocation parameter is provided, a comma is inserted in its place. 


Example 3: Multifile Restore from Multivolume Tapes Using Separate Device Assignment Sets 


// SOB TFILRST3 

// DVC 28 // LFD PRNTR 

// DVC 9@ // VOL BACK@1 // LFD TAPEIN 
// DVC 91 // VOL BACK@2 // LFD TAPEING1 
// DVC 92 // VOL BACK@3 // LFD TAPEIN@2 
// DVC 93 // VOL BACK®4 // LFD TAPEIN@3 
// DVC 5@ // VOL MYPACK // LFD DISCOT 
// EXEC DMPRST 

// PARAM IN=TAPE 

// PARAM OUT=DISC 

// PARAM TYPE=FILE 


/$ 
FILE RPGII,REL,RPGII01 
FILE MYCOBOLMASTER, ABS 
FILE PROCFILE, ,PROCFILE@2 
FILE ''PAY BACKUP'! 

/* 

/& 

// FIN 


This job stream is the same as the job stream in Example 2. In this example, however, 
each tape volume is assigned via an individual device assignment set. The tape 
volumes are mounted simultaneously on separate tape drives. 


Restoring Multiple Disks from Tape in File Mode 


If you are restoring from a tape created from multidisk inputs, use the LFD 
statements TAPEIN and DISCOT01, DISCOT02,...DISCOTnz. 


The input parameter is // PARAM IN=TAPE and the output parameter is // PARAM 
OUT=DISC(D01 ,D02,...Dnn), where the numerics of the Dnn statements must 
correlate with those in the LFD statements. The numerics associated with each disk 
must be the same as those used on the LFD and Dnn statements when the input tape 
was created. The numerics need not be contiguous. 
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DISC data statements are associated with each Dnn statement. One of them must 
precede any FILE statements associated with a disk. 


Files that are dumped from two different disks cannot be restored to one disk, nor can 
files dumped from one disk be restored to two different disks. The Dnn identifier is 
always associated with the file on the output tape. 


You cannot specify ALL on the TYPE=FILE statement when doing a multidisk 
volume restore, nor can you use the global allocation parameters. 


The JCL required to restore the PAYROLL file dumped in the example in “Dumping 
Multiple Disks to Tape in File Mode’ earlier in this subsection is as follows: 


// JOB RESTORE 

// OVC 20 // LFD PRNTR 

// DVC 98 // TAPEQO® // LFD TAPEIN 

// DVC 58 // VOL DISCAA // LFD DISCOT@1t 
// DVC 51 // VOL DISCCC // LFD DISCOT@3 
// EXEC DMPRST 

// PARAM IN=TAPE 

// PARAM OUT=DISC(D01,D03) 

// PARAM TYPE=FILE 


/$ 
DISC D@1 
FILE PAYROLL 
DISC De3 
FILE PAYROLL 

/* 

/& 


Restoring from a Diskette in File Mode 


If you are using diskette as input, specify // PARAM IN=SEQD as your input 
parameter, and SEQDIN as the file name on your diskette’s // LFD statement. Only 
specify a single device assignment set (DVC-LFD sequence) when multivolume 
diskettes are used. 


Since you are executing DMPRST in file mode, include the // PARAM TYPE=FILE 
parameter in your job stream. Also, include the necessary FILE statements as 
embedded data in your job stream. Remember that the files must be restored in the 
same order as they were dumped. 


Unlike the tape restore operation, when restoring from diskettes you must provide a 
file statement for every file that was dumped in the related dump operation. In a tape 
restore, if you want to prevent a file from being restored, simply omit the FILE 
statement for that file. In a diskette restore operation, however, to prevent a file from 
being restored, specify the SKP parameter on the file’s FILE statement (i.e., FILE 
MYFILE,SKP). 
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In a multivolume diskette restore operation, you can start restoring from a volume 
other than the first volume by specifying the ANY parameter on the // PARAM 
TYPE=FILE statement. When ANY is specified, DMPRST searches the mounted 
diskette for the file name specified on the FILE statement. Any files preceding the 
specified file on the volume are skipped. 


The following two examples show typical restore operations using diskettes: 
Example 1 


// JOB STORST@1 

// OVC 20 // LFO PRNTR 

// DVC 138 // VOL SAVE@1,SAVE@2, SAVEO3, SAVEG4 
// LBL DATA // LFD SEQDIN 

// DVC 5@ // VOL MYPACK // LFD DISCOT 

// EXEC DMPRST 

// PARAM IN=SEQD 

// PARAM OUT=DISC 

// PARAM TYPE=FILE 





/s 
FILE INVENTORY 
FILE PARTS,SKP 
FILE INVOICES 

/* 

7% 

// FIN 


All the files that were dumped to diskette by the dump operation in 12.5.2, except 
PARTS, are restored to the disk volume, MYPACK. Notice that because the files are 
restored from diskette, all the files that were dumped are listed even though the 
PARTS file isn’t being restored. The SKP parameter in the second FILE statement 
prevents PARTS from being restored. 


Since the files INVENTORY, PARTS, and INVOICES are stored in the MIRAM file 
(DATA) on diskette, the LBL name DATA is included in the diskette’s device 
assignment set. Note that the files are restored in the same order they were dumped. 


The only parameter used in the FILE statements is the old-name parameter. Since 
the allocation parameter is omitted from these FILE statements, standard restore 
processing is performed (see “Using the Allocation Parameter to Control Restore 
Processing” earlier in this subsection). 
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@ Example 2 


// JOB RESTART 
// DVC 20 // LFD PRNTR 
// DVC 138 // VOL, ,SAVE@3, SAVEO4 
// LBL DATA // LFD SEQDIN 
// OVC 58 // VOL MYPACK // LFD DISCOT 
// EXEC DMPRST 
// PARAM IN=SEQD 
// PARAM OUT=DISC 
// PARAM TYPE=FILE,ANY 
/$ 
FILE INVOICES 
/* 
/& 
// FIN 


In this restore operation, the parameter ANY is specified on the // PARAM TYPE 
statement enabling DMPRST to begin restoring from a volume other than the first 
one. DMPRST checks the file name on the FILE statement as the starting point for 
the restore operation. Any files preceding the starting point (INVOICES) are skipped. 


Note: When diskette volumes are being skipped, the omitted volume serial numbers 
must be indicated by commas. 


Restoring from a MIRAM Disk File in File Mode 


Since the input disk in a restore operation is a different type from the original, specify 
// PARAM IN=SEQD as your input parameter, and SEQDIN as the file name on your 
input disk’s // LFD statement. 


You must include the name of the input disk’s MIRAM file in your control stream. 
This is the same name that was assigned for the related dump operation. Remember, 
only a single device assignment set may be used to assign your input disk volumes. 


Since you are executing DMPRST in file mode, include the // PARAM TYPE=FILE 
statement in your job stream. You must also supply the appropriate FILE statements 


as embedded data. Remember, the files must be restored in the same order in which 
they were dumped. 
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The following example shows a restore operation using a disk: 


// JOB STDRSTO2 

// DVC 20 // LFD PRNTR 

// DVC 5@ // VOL BACKUP // LBL FILESAVE // LFD SEQDIN 
// DVC 51 // VOL D88@88 // LFD DISCOT 

// EXEC DMPRST 

// PARAM IN=SEQD 

// PARAM OUT=DISC 

// PARAM TYPE=FILE 


/$ 
FILE INTERESTPRG 
FILE MORTGAGEPRG 
FILE BALANCE 

/* 

/& 

// FIN 


The files that were dumped to disk by the dump operation in Example 1 of “Dumping 
to a MIRAM Disk File in File Mode” in 12.5.2 are restored to the disk volume D88088. 
This volume is not the original volume (D00309), but it’s the same type disk as the 
original. 


Since the allocation parameter is omitted from the FILE statements, standard restore 
processing is performed. Remember, the files must be restored in the same order in 
which they were dumped. 


Performing a Diskette Copy Operation in File Mode 


You can copy the contents of a set of diskettes created in file mode to another set of 
diskettes. Unlike the disk copy operation, however, you cannot copy individual files. 
Instead, the entire contents of the diskette are copied. 


Input and output in a diskette copy operation are always diskettes. Therefore, 

/1 PARAM IN=SEQD and // PARAM OUT=SEQD must be specified along with the file 
names SEQDIN for input and SEQDOT for output. Also, since you are performing the 
diskette copy operation in file mode, include the // PARAM TYPE=FILE parameter in 
your job stream. 


The following is an example of a typical job stream used to perform the diskette copy 
operation: 
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// JOB COPYDSKT 

// DVC 20 // LFD PRNTR 

// OVE 138 // VOL COPY@1,COPY@2,COPY@3 
// UBL DATA // LFO SEQDIN 

// DVC 131 // VOL COPY@A, COPY@B, COPY@C 
// LBL DATA // LFD SEQDOT 

// EXEC DMPRST 

// PARAM IN=SEQD 

// PARAM OUT=SEQD 

// PARAM TYPE=FILE 

/& 

// FIN 


The contents of the diskette set, COPY01, COPY02, COPY03, are copied to the 
diskette set, COPYOA, COPYOB, COPY0C.COPY02. Since the DATA file was allocated 
to each diskette during prep, the LBL name, DATA, must be supplied in each device 
assignment set. 


12.5.5. Copying Files in a Single-Disk Environment 


You can make copies of a file on the same disk using the new-name parameter of the . 
FILE statement. Here, the copy you create is written on the same disk as the original 
file. The new file, however, is assigned a new file name. 


@ Since the same disk is used as both the input and output volume, the same device 
must be assigned having the // LFD names of DISCIN and DISCOT. Also, specify 
// PARAM IN=DISC and // PARAM OUT=DISC. 


The new-name parameter of the file statement must be specified when you're copying 
files on the same disk, since two files with the same name can’t exist on the same disk 
volume. With the new-name parameter, you can copy the file and give it a new name. 


For example, suppose you are copying the MYFILE file on your disk. In order to copy 
MYFILE, specify the name MYFILE02 as the new-name parameter on the FILE 
statement. 


In this case, DMPRST first scratches any file having the name MYFILE02 from the 
disk. Next, DMPRST allocates a file large enough for MYFILE. The old file, MYFILE, 


is then copied to the allocated space and given the new name, MYFILE02. Now, two 
identical files having different file names exist on the same disk. 
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The following example shows a single-volume file copy operation: 


// JOB FILCOPY 
// OVC 20 // LFD PRNTR 
// DVC 58 // VOL DISK91 // LFD DISCIN 
// OVC 5@ // VOL DISK@1 // LFD DISCOT 
// EXEC DMPRST 
// PARAM IN=DISC 
// PARAM OUT=DISC 
// PARAM TYPE=FILE 
/$ 
FILE MYFILE, ,MYFILE@2 
/* 
// FIN 


A copy of the MYFILE file on disk volume DISK01 is written to another location on 
the same disk. Note that the same disk is assigned as input and output. 


Here, DMPRST first scratches any file on the disk having the name MYFILE02. Next, 
DMPRST allocates a file large enough for MYFILE. The old file, MYFILE, is then 
copied to the allocated space and given the name MYFILEO2. 


Restarting a Dump/Restore Operation 


You can use the DMPRST routine to restart a diskette or tape dump or restore 
operation that terminated prematurely. This saves you from rerunning the entire job. 
This restart function, however, can only be performed when dumping from a disk to 
diskette or tape, or when restoring from diskette or tape to disk. 


You can restart a diskette or tape DMPRST operation in either volume or file mode. In 
the following paragraphs, we will discuss the procedures for restarting diskette and 
tape DMPRST operations and will emphasize the differences between the two modes. 


Restarting a Diskette Dump/Restore Operation 


The first step in restarting a DMPRST job is to mount the correct diskette volume. 
You must mount a diskette that was completely processed before the original job 
terminated. If you don’t know which volume was completed last, select a volume you 
are sure was completed. 


For example, suppose you are restoring the file named MYFILE from diskette 
volumes A, B, C, D, E, F, and G to disk, and you aren’t sure whether volume D was 
completed at the time the job was terminated. In this case, you should mount either 
volume B or C, since you know these volumes were completed. Remember, however, 
that you cannot mount the first volume of a diskette file when performing a restart. 
So, in this example, the first volume of MYFILE, volume A, can never be used to 
restart. 
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The second step in restarting your DMPRST job is to revise the statements in your 
original job stream. You will later run this revised job stream to restart your job. 


Consider the // VOL statements. Because you are not using all of the original volumes 
in your restart operation, make changes to the // VOL statements in your control 
stream. The volume serial numbers of the diskettes not being used in the restart 
operation must be replaced by commas. So, if you originally specified 


// VOL A,B,C,D,E,F,G 


and you're restarting the job with volume C, you would change your // VOL statement 
to the following: 


4/ VOL 1eC,D,E,F,G 


Note that volumes A and B in this example are replaced by commas. You can also 
replace the original // VOL statements with a single // VOL SCRATCH statement. 
While this statement eliminates the need to specify any volume serial numbers in 
your restart control stream, it suppresses data management’s checking for the proper 
volume serial numbers. Therefore, ensure that the operator knows exactly what 
volumes to mount and the proper sequence in which to mount them. For more 
information on the // VOL statement and the // VOL SCRATCH statement, see the 
Job Control Language Programming Guide (UP-9986). 


Before restarting your job, add the statement // PARAM RESTART to the set of 
PARAM statements in your revised job stream. This statement activates the DMPRST 
restart function. 


At this point, if you are running DMPRST in volume mode, you are ready to initiate 
the restart function by running your revised job stream. However, if you are restarting 
a restore operation in file mode, consider the following: When you are restarting a 
restore operation in file mode, include the same FILE statements in your restart job 
that were used in the terminated restore job. So, if your original restore job contained 
FILE statements using the SKP parameter (see 12.5.3), include these statements in 
the restart job. 


The following examples are used to show a restart procedure. The first example is the 
control stream for the original job. The second example is the control stream used to 
perform the actual restart. 
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Example 1: Original Diskette File Restore Operation: 


// JOB DSKTRST 

// DVC 20 // LFD PRNTR 

// DVC 138 // VOL DSKTO1,DSKT@2,DSKT@3 , DSKTO4, DSKT@S , DSKT@6 
// LBL DATA // LFD SEQODIN 

// DVC 5@ // VOL MYPACK // LFD DISCOT 

// EXEC DMPRST 

// PARAM IN=SEQD 

// PARAM OUT=DISC 

// PARAM TYPE=FILE 


/$ 
FILE INVENTORY 
FILE PARTS, SKP 
FILE INVOICES 
FILE CREDITS 
FILE PAYMENTS, SKP 

/* 

/& 

// FIN 


Example 2: Restart Control Stream for Original Job 


// SOB DSKTRST 

// DVC 20 // LFD PRNTR 

// DVC 130 // VOL ,,,,DSKT@4, DSKT@5, DSKT@6 
// LBL DATA // LFD SEQDIN 

// DVC 5@ // VOL MYPACK // LFD DISCOT 

// EXEC DMPRST 

// PARAM IN=SEQD 

// PARAM OUT=DISC 

// PARAM RESTART 

// PARAM TYPE=FILE 


/$ 
FILE INVENTORY 
FILE PARTS,SKP 
FILE INVOICES 
FILE CREDITS 
FILE PAYMENTS, SKP 

/* 

sk 

// FIN 


The restart control stream in Example 2 is basically the same as the original control 
stream. In the original job, however, DMPRST was processing DSKT05 when it 
terminated. Therefore, DSKT04, the last volume completely processed, is mounted 
first for the restart job. Notice that the volume serial numbers of the diskettes not 
being used in the restart job are replaced with commas. The remainder of the control 
stream in Example 2 is identical to the original, except for the // PARAM RESTART 
statement that is added to activate the restart function. 


UP-8841 Rev. 4 











Disk Dump/Restore (DMPRST) 


12.6.2. Restarting a Tape Dump/Restore Operation 


You can restart a tape dump or restore operation that terminated prematurely, unless 
the tape was created with a release prior to Release 12.0. 


When restarting a tape operation, refer to the output of the original job. DMPRST 
issues messages to indicate when a tape is being read or written. It also issues a 
message when it is finished reading (closing) a tape. Mount a tape that DMPRST has 
already written to or read from; or, if restoring, mount the next volume after one that 
was closed. The first volume of the operation can never be mounted for a restart; the 
original job must be rerun. 


The original job control stream must be altered for the restart. If the original // VOL 
statement for the tapes appears as 


// NOL TAPE@1, TAPE@2, TAPE@3 


and DMPRST started to read (write) tape02, the statement must be changed as 
follows: 


// VOL ,,TAPE@2, TAPE@3 
Note that an extra comma must be entered. 
A// PARAM RESTART statement must also be added to the job stream. 


At this point, if you are running DMPRST in volume mode, you are ready to restart by 
running your revised job stream. However, if you are running in file mode and you are 
restarting a restore operation, some changes may be required for the FILE statements 
if you are not restoring all files. A FILE statement with a SKP parameter (see 
“Restoring from a Diskette in File Mode” in 12.5.3) must be added for any file that is 
not being restored and that precedes one on the tape that is being restored. 


The following example shows a restart for a tape restore. The first control stream is 
for the dump that created the tape input for the restore. The second is the control 
stream for the restore. The third is for the restart. 
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The following is the control stream to dump the files: 


// SOB TAPEDUMP 
// DVC 20 // LFD PRNTR 

// DVC 98@°// VOL TAPE@1, TAPEQ@2,TAPE@3 // LFD TAPEOT 
// DVC 5@ // VOL MYPACK // LFD DISCIN ; 

// EXEC DMPRST 

// PARAM IN=TAPE 

// PARAM OUT=DISC 

// PARAM TYPE=FILE 


/$ 
FILE INVENTORY 
FILE PARTS 
FILE INVOICES 
FILE CREDITS 
FILE PAYMENTS 

/* 

/& 

// FIN 


The following is the control stream for the original restore job (Note that the 
INVENTORY and PARTS files are not being restored.): 


// JOB TAPERSTR 

// OVC 20 // LFD PRNTR 

// DVC 9@ // VOL TAPE@1,TAPE@2,TAPE@S // LFD TAPEIN 
// OVC 50 // VOL MYPACK // LFD DISCOT 

// EXEC DMPRST 

// PARAM IN=TAPE 

// PARAM OUT=DISC 

// PARAM TYPE=FILE 





/$ 
FILE INVOICES 
FILE CREDITS 
FILE PAYMENTS 

/* 

1% 

// FIN 
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The following is the restart control stream: 


// JOB TAPERSTR 

// DVC 20 // LFD PRNTR 

// DVC 90 // VOL ,,TAPE@2,TAPE@3 // LFD TAPEIN 
// OVC 5@ // VOL MYPACK // LFD DISCOT 

// EXEC DMPRST 

// PARAM IN=TAPE 

// PARAM OUT=DISC 

// PARAM TYPE=FILE 

// PARAM RESTART 


/$ 
FILE INVENTORY, SKP 
FILE PARTS,SKP 
FILE INVOICES 
FILE CREDITS 
FILE PAYMENTS 

/* 

/& 

// FIN 


12.7. Checking for File Expiration Date 


&@ DMPRST routine automatically checks for file expiration dates on your output volume 
thus saving you the time and expense of keeping outdated files. DMPRST checks the 
file expiration date by comparing that date with the system date. If the date has not 
expired, a message is displayed asking you to process the file, ignore the date, or 
terminate the job. The expiration date function is used in both volume and file modes 
when copying or restoring files. 


To suppress the file expiration date checking feature, specify the // PARAM 
NOEXPCK statement. The following example is a typical control stream using the 
expiration date checking function in file mode. In this example, the file expiration date 
function is done automatically (omit the // PARAM NOEXPCK) in restoring disk files 
from diskette. In addition, specify the FILE PREFIX statement to restore all files 
having the prefix MAST. 
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// JOB DSKTRST 
// DVC 20 // LFD PRNTR 

// DVC 130 // VOL DSKT@1,DSKT@2,DSKT@3, DSKT@4, DSKT@S , DSKT@6 
// LBL DATA // LFD SEQDIN 

// OVC 5@ // VOL MYPACK // LFD DISCOT 

// EXEC OMPRST 

// PARAM IN=SEQD 

// PARAM OUT=DISC 

// PARAM TYPE=FILE 


/$s 
FILE INVENTORY 
FILE.P MAST 
FILE INVOICES 
FILE CREDITS 

/* 

/& 

// FIN 


12.8. Listing Files on an Input Medium 


You can print a list of the files backed up on a tape, a diskette, or a MIRAM file on 
disk by specifying LIST on the TYPE=FILE parameter. 


The following example shows a list operation from tape: @ 


‘f/f SOB LIST 

// DVC 20 // LFD PRNTR 

// OVC 98 // VOL TAPE1 // LFD TAPEIN 
// EXEC DMPRST 

// PARAM IN=TAPE 

// PARAM TYPE=FILE,LIST 

/& 
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Section 13 | 


List Software Maintenance Corrections 
(SMCLIST) 


13.1. SMCLIST Function 


You can use the SMCLIST canned job control stream to print a listing of the software 
maintenance corrections contained in the SMCLOG file. This listing may be printed in 
either a full or a condensed format. Also, by specifying certain parameters, you can 
produce listings sorted by SMC number, component number, program-product-type 
number, date, and time. 


13.2. Executing SMCLIST 


The format of the SMCLIST canned job control stream is 





RV SMCLIST|,|,FMT= {F)||,SEQ1=/ COMP ,SEQ2= { COMP [weve] 
{e} DATE DATE 
TIME TIME 
PP-TYPE PP-TYPE 
nnnn-nn nonn-nn 
where: 


FMT= {F 
Specifies the format of the listing being produced. 


FMT=F 
Specifies that a full listing is printed. 


FMT=¢ 
Specifies that a condensed listing is printed. 
A full listing is a listing sorted primarily by component number and then by SMC 


number. It gives more information about each SMC than a condensed listing, 
such as the regenerations an SMC requires or the method used to install it. 
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Since you don’t always need as much information as the full listing shows, we 
also provide a condensed listing. A condensed listing contains only SMC numbers 
in ascending order and an indication of whether any SMCs were backed out, 
replaced, or were not installed because of an error during installation. (See 
Figures 13-1 and 13-2 for an example of each listing.) 


The default for the FMT parameter is C for condensed. Unless you specify 
FMT=F on your SMCLIST run command, you will always receive a condensed 
listing of the SMCs in the SMCLOG file. 


SEQ1= 
Specifies the primary sorting key to be used. 





Specifies the component number. 


SEQ1=DATE 
Specifies the date that the SMCs were applied. 


SEQ1=TIME 
Specifies the time that the SMCs were applied. 


SEQ1=PP-TYPE 
Specifies the program-product-type number. 





SEQ1=SMC# 
Specifies the SMC number. 


SEQ1t=nnnn-nn 
Specifies that only those SMCs with a program-product-type number of 
nnnn-nn will be printed. 


If you omit the SEQ1 keyword, the full listing is sorted primarily by 
component number. 


SEQ2= 
Specifies the secondary sorting key to be used. 


SEQ2=COMP 
Specifies the component number. 


SEQ2=DATE 
Specifies the date that the SMCs were applied. 


SEQ2=TIME 
Specifies the time that the SMCs were applied. 


SEQ2=PP- TYPE 
Specifies the program-product-type number. 
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se02=SHeH 
Specifies the SMC number. 


SEQ2=nnnn-nn 
Specifies that only those SMCs with a program-product-type number of 
nnnn-nn will be printed. 


If you omit the SEQ2 keyword, the secondary sorting key is the SMC 
number. 


V=vsn 


Specifies the volume serial number for a system release pack other than 
RES. 


Notes: 
1. The SEQ1 specification may not be the same as the SEQ2 specification. 


2. Ifnnnn-nn is specified for the SEQ1 or SEQ2 parameter, any SMCs that were 
replaced do not appear in the listing. 


The condensed listing in Figure 13-2 shows all of the SMCs contained in the SMCLOG 
file. It is sorted by SMC number and shows all the SMCs in ascending order. Some of 
the SMCs show codes after them indicating that they were 


@ e Replaced by Unisys because they produced adverse effects on OS/3. Any SMCs of 
this kind show a code of -R after them, for example, C082187-R. 


¢ Backed out by you under the direction of a Unisys representative because they 
produced adverse effects on your particular system. Any SMCs of this kind show 
a code of -B after them, for example, C082005-B. 


¢ Not applied to your system because of an error during installation. These SMCs 
are followed by a code of -E, for example, C082058-E. 


Note: An additional code of -I may also appear on your condensed listing. This code 
applies to non-SMC records and indicates that Unisys recorded information 
about that record in the SMCLOG file to be used by the SMC job stream. You 
can ignore any records containing this code. 
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OS/3 S¥C LOG FILE DISPLAY 


SMC 
NUMBER 


CG71187 
Co7195” 
CuT216° 
Curc23” 
Cu72289 
Fa7236% 
Ca72467° 
CI72509 
cu72524 
cu7zs39 
Cur2z642 
£u72667 
Cu7271£ 
Culz76? 
CutZ6a7 
Yo7o011 
cu7221°e 
Cu7Z29€ 
Ca72n27 
COT247€ 
ca7v2u7e 
Ca72087 
co72s2> 
7u72532 
CO72249 
Cul2s77 
Co7z$1" 
CO72392 
CO7263% 
COT2 361 
Cu7Z62& 
Cu72437 
C5728590 
CJ72872% 
COTZI9E 
Cu72472 
co7281"% 
CO72679 
CuT2eoeb 
Cu73973 
Cu72274 
Cu7252! 
Cu725B¢ 
COTLISE 
COT2N1& 
Cu72210 
CQ72233 
CO7T227£ 
Cur22g¢ 
CO72334 


come 


@ 
aoag 
atgo 
aoa 
ANYO 
ann 
anya 
argyn 
a339 


-40u0 


ann 
Agu 
Anygn 
Angn 
acoo 
Aouad 
Ango 
AQ 
aoir 
ania 
Ann 
Aoiga 
a0igs 
aol 
amic 
AMI 
agmil 
AQli 
4312 
4012 
Anis 
ania 
agis 
An14 
AO1LG 
atls 
Aols 
Aois 
agis 
aais 
4015 
agi? 
agig 
agg 
anea 
4029 
aag2g 
anen 
agen 
ao20 
ag2a 


PP-~TYPE 
NUM REP 


b2in-ny 
6219-95 
6219-06 
6233-00 
O21N-Ny 
621 7-Ny 
6219-70 
6213-CO 
6213-00 
6219-0 
6219-0 
O2L7-Ry 
6219-Fy 
6219-05 
6219-90 
6217-9 
6214-75 
6216-9 
6215-9 
6216-%y 
6216-54 
6216-29 
3216-95 
6215-05 
6219-Py 
621 7-My 
5219/9" 5 
d214-09 
6214-03 
6213-00 
6210-00 
s2in-ry 
6219-"% 
6213-00 
o21I-My 
621 7-Py 
219M 
6219-0y 
6219-96 
6219-09 
62190-C0 
6216-CU 
6216-0 
6219-9 
6210-00 
$219-00 
6210-00 
6219-Mu 
6210-FG 
6219-Ny 


SYSTEN 


® 
BLONLY 
9GONLY 
8UONLY 


CUMMON 


COMMON 


Figure 13-1. Sample of Full SMC Listing (Part 1 of 2) 


RELEASE-10=12.0.0 -1 
REQUIRED 


RE-GENS 
® 


yes 


YES 


FORMAT oF 


Dare 


12/17/8y 
12/17/83 
12/17/80 
01/1078) 
12717760 
017inseal 
M7i%781 
Pisinsay 
1726/81 
01726,/8)1 
92/1078) 
02/1078) 
Fe/4°78) 
M3/u7/8) 
RZ/1A/81 
#74u97/91 
12/17/84 
12/17/86 
9172678, 
74/178) 
Ms iAsAL 
1719781 
Missal 
91723781 
12417783 
Ni7Z6781) 
Piscss/Ri 
M/s 781 
1/27/81 
12/17/8u 
04719761 
3374978) 
03/31/84 
3731/81 
01719761 
91/10/86) 
Mi7inse1 
M2/1P 7/8) 
PP 3/7/81 
97/09/81 
91/1078) 
91710781 
91726/81 
8u/8N7B9 
12/17/88 
12/17/8u 
12417783 
12/17/60 
12/17/80 
12/17/89 


SEQ1= 


TIME 


15385 
15354 
15:87 
16:3u 
15359 
16:33 
36:37 
16:4) 
19:79 
19:5¢ 
47342 
18:85 
1957) 
15:78 
13343 
33:22 
16372 
16:0u 
18:53 
16:43 
16:44 
16:46 
16:48 
lasrs 
16311 
21:31 
23:82 
16:49 
vw i36 
16:13 
16:5) 
16:52 
12:41 
12346 
16:54 
16:56 
16:57 
18:87 
15:32 
’2:4u 
16:56 
17:00 
22:25 
60:80 
16:2u 
16:22 
16:24 
16:25 
16:27 
16:29 


COMP 


APPLICATION 


METHOD 


Smc 
SMC 
SMC 
smc 
SMC 
smc 
SMC 
SMC 
SMC 
SMC 
smc 
smc 
sac 
SMC 
s¥C 
SMC 
sec 
SMu 
SMC 
SMC 
Suc 
SMC 
SMC 
SMC 
SMC 
smc 
SMC 
sec 
SMC 
SMC 
SMC 
SHC 
smc 
SMC 
smc 
S4C 
SMC 
Smc 
SMC 
SMC 
SMC 
SMC 
SMC 
SMC 
SMC 
SMC. 
SMC 
SMC 
SMC 
sec 





SEQ2=SMCe 


CHARACTER 
e 


07/25/88 


SMC/SMP STATUS 


wor 
Nor 
No’ 
wor 
NoT 
Not 
nor 
not 
Nor 
Not 
Nort 
NOT 
Nor 
Nor 
NOT 
@ePUN 
uQOT 
NOT 
NOT 
wot 
NOT 
NOT 
nor 
NO” 
MoT 
NoT 
Nor 
MOT 
NOT 
NoT 
wor 
nor 
NoT 
NGY 
Nor 
NOT 
NOT 
MOT 
NOY 
NoT 
wor 
nor 
nor 


H 


RACKED-uP 


BACKFO-uP. 


RaCKFO-yP 
RACKFO-UP 
PACKFD-ue 
BACKED-ue 
SAaCKED-uP 
BACKED-uP 
PACKFD-yP 
RACKFO-uP 
PACKEO-uP 
PACKEO-uP 
BACKFEO-uUPm 
RACKFO-ue 
RACKFD-UP 
OROCF SSOP 
PacKey-ue 
PACKFD<uP 
9aCKFU-uP 
PACKFO-uP 
PATKFD-uP 
BaCaFb-uP 
SaCKEL-uP 
PACKFD-uP 
RaCKFu-uP 
RACKEO-uP 
PAC KFO-uP 
BACKFO-uP 
QaCKFO-uP 
RaCKFO-uP 
PACKEU-UP 
PACKFO-uP 


-PACKFO-uP 


PaCaFO-ue 
PACKFO-uP 
BACKED-uP 
RACKEG-uP 
PACKFEO-uP 
BACKFO-uem 
BACKEG-uP 
PACKFD-um 
BACKED-uP 
PACKFD-ue 


@ePROGPAM FRPOP 


Nor 
Nor 
NOT 
Nor 
nor 
Nor 


PACKFO-uP 
PACKFO~uP 
RACKFD=uP 
BACKFO-uP 
BACKED-uP 
BACKFED-uP 





17:38 


FRPOP 
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OS/3 SMC LOG FILE DISPLAY. RELEASE-!02 12.0.0 <-1 FORMAT =F 
REQUIRED APPLICATION 


SMC 
NUMBER 


CG72349 
Cu72502 
co7252¢ 
Cu72561 
Co727u° 
CG72324 
cO72347 
Cu72387 
CY72531 
Cu7lag* 
Cu71577 
cO7c234 
CO7Z272 
Ca72eis 
Cu72597 
Co7215t 
Cu721s¢ 
co?290° 
Cut2eat 
Cu7285% 
cCu72952 
Cul2462 
Cut258° 
cu7235? 
ct 724a? 
cc72577 
Cu72517 
Cg72728 
Cy7273"% 
CuUTZ10£ 
Culzi72 
co7235° 
CUT257£ 
cuv217° 
Cu72558 
Co729$! 
cu724a1° 
cu72567 
Cu7218° 
co72197 
cOr22uz 
C072277 
Cu723u8 
CU72327 
C572 368 
CO7262£ 
CO725S56 
co72s72 
Cu72589 
co72599 


COMP 


@ 
ao20 
ag2zo0 
ageo 
agen 
anen 
an2) 
ANC? 
AN22 
AM22 
agz3 
an23 
an23 
4923 
an23 
an23 
ages 
anv2u 
An24 
an2o 
A024 
aAn26 
4024 
Anzy 
an25 
A025 
an2s 
An26 
ane? 
Ane? 
aso 
aas' 
anst 
aoso0 
anen 
anon 
ango 
alin 
allo 
a120 
4129 
Al2o 
al2o 
aien 
4120 
a12o 
al2o 
al2o 
al2i 
Al2i 
at2i 


PP-TYPE 
NUMBER 


® 
6210-00 
6210-00 
6219-0 
621 97-Ru 
6710-"G 
6219-fu 
6213-08 
6211-09 
6219-00 
6219-%yu 
6287-70 
621N-%yu 
6213-99 
6213-09 
6219-90 
O21T-%y 
6219-Py 
b2lg-Fy 
6213-09 
6217-90 
$213-06 
o21I-Ry 
6217-PL 
621% 
6219-00 
$719-09 
6210-0 
219A 
6219%-My 
6217-9 
$219-00 
XMM AOKX 
$213-C3 
6213-03 
6219-Fy 
6219-75 
6233-Pu 
6233-"y 
6219-09 
6217-00 
6219-00 
6219-NMu 
6219-9 
6217-M"uU 
6219-79 
6219-00 
6219-00 
6220-Nu 
6220-0 
6220-T) 


SYSTER eee DaTE 


12/17/8u 
1/19/81 
91/26/81 
01/26/81 
YES nesiisar 
12/17/8y 
12717/8y 
mis insey 
01/26/63 
91730781 
1710781 
12/17/8y 
12/17/86 
1/26/61 
1/26/81 
12/17/83 
12717783 
774978) 
a7 e3/81 
4/23/81 
94719783 
01/10/83 
01/26/81 
12717784 
PizinsB8. 
1/26/81 
9171078) 
92/10781 
02/10/81 
12/17/8u 
12/47/89 
M4y/23781 
4/26/81 
12/18/89 
4726781 
913710781 
71/1978) 
P1/726/821 
12/18/Be 
12/18/84 
12/18/89 
12/18/80 
12/18/89 
12/167/8y 
12/18/80 
1/27/81 
n271078)1 
01/26/82 
01/26/78) 
7172678) 


SEQI=COMP 


TIME 


16:31 
1731 
19:35 
20:53 
12:11 
46:33 
16:35 
17:02 
19:41 
417;04 
17:6 
16:37 
46338 
1a:39 
22:49 
36:40 
16:41 
17:ne 
133138 
13315 
17:22 
17325 
22:31 
16:83 
17:27 
21:50 
17328 
1939 
19:12 
16:45 
16:47 
14:07 
21:43 
a4sta 
20:35 
17331 
17333 
21:16 
14:12 
14315 
19:18 
44320 
19323 
19:24 
34:27 
uMs29 
1esn2 
21337 
22:36 
23321 


METHOD CHARACTER 
@ ® 


SMC 
smc 
smc 
smc 
SMC 
SMC 
SMC 
SMC 
SMC 
smc 
smc 
smc 
SMC 
Sac 
SMC 
smc 
SMC 


“SMC 


SPC 
SMC 
SMC 
Sec 
SMC 
SMC 
SMC 
sec 
SMC 


SMC 
SMC 
SMC 
Smc 
smc 
Sac 


Figure 13-1. Sample of Full SMC Listing (Part 2 of 2) 


SEQ2=SMCH 


07/25/88 


SMC/SMP STATUS 
® 


NoT 
Not 
NoT 


.NOT 


wor 
NOT 
woT 
Not 
NOT 
wor 
NoT 
NOT 
NOT 
NoT 
Not 
NOT 
NOT 
NoT 
MoT 
wot 
NOT 
wot 
Not 
NOT 
NoT 
Nor 
NoT 
NOT 
NoT 
NoT 
Nor 
NoT 
wor 
NoT 
nor 
NoT 
Not 
NoT 
NOT 
wor 
NOT 
NoT 
nor 
NOT 
not 
wor 
Nort 
wor 
wor 
NoT 


BACKFO-uP. 


BACKED-uP 
BACKFU-UP 
BACKFEO-uP 
RACKFD-uUP 
BaCKf€O-uP 
PACKFO-uP 
PACKFO-uP 
PACKFD-uP 
BACKFED-uP 
PACKED-uP 
RACKED-uUP 
RACKFD-uP 
RACKED-yP 
RACKEG<UP 
PaCKFO-uP 
BaCKFD-uP 
RaCKFD<-ue 
RACKED-uP 
PACKED-yuP 
RACKED-uP 
PACKFU-Ur 
RaCKFDeuP 
RACKEL-uP 
PACKEO-uP 
RACKFE OUP 
RACKFO-uP 
BACKFD-uP 
PACKFD-uP 
BACKED-uP 
RACKFD-uP 
PaCKEO-uP 
BACKFD-uP 
RACKFO<uP 
RACKFO-<uP 
RACKEG-UP 
PACKFD-uP 
RACKED=ue 
PACnFO-uP 
PACKFD-uP 
PACKFU-uP 
PACKFO-uP 
PACKEU~uP 
BACKED-uUP 
BACKEO-uUP 
PACKED-uP 
PACKEO-UP 
BACKED-uUP 
BACKED-uP 
RAaCKED-uP 


17:38 
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Field 
SMC NUMBER 
COMP 


PP-TYPE 
NUMBER 


SYSTEM 


REQUIRED 
RE-GENS 


APPLICATION 
DATE - TIME 


METHOD 


CHARACTER 


SMC/SMP 
STATUS 


Description 

Software maintenance correction number assigned. 

Software component number (internal use'only). 

Program product type number; e.g., control system (6210), etc. 
No entry indicates SMC is common to both models 6 and 8; 
80 indicates SMC pertains only to models 8 through 20; 

90 indicates SMC pertains only to model 6. 


YES indicates some SYSGEN was required; 
no entry indicates SYSGEN was not required. 


Date and time SMC or SMP were applied. 


SMC applied via the librarian; 
SMP applied via dump/restore. 


No entry indicates SMC/SMP was required; 
OPTIONAL indicates SMC/SMP was not required. 


NOT BACKED UP indicates SMC/SMP cannot be deleted but 
was successfully applied. 


NOT APPLIED,DEPENDENCY indicates other SMCs not 
contained on the volume were needed; SMC/SMP not applied. 


**SMC LOOPED indicates SMC not applied because specified 
time limit was exceeded for applying SMC. 


**SMC EXECUTION ERROR indicates SMC was not applied 
due to abnormal termination. 


** RUN PROCESSOR ERROR indicates SMC not applied due 
to SMC not being scheduled. 
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OS/3 SC LOG FILE V=12.0.8 RELEASE-ID= 12.0.0 -A FORMAT=C SEQ1=COMP SEQ2=CmC# 02/04/88 95:16 PAGE=0001 
R = REPLACED 6 - BACKED OUT I - INFORMATION ONLY F ~ OTHEP ERPOR 


CLEIRI? «= CLA1819 «= CUB 1912 «= CUB2084 = 082086 ~= CLBzZ089 ~= 082091 «CCB 1799 CORAR42-E CORZNG? CORZDNG6 682056 
COFIPS? CcBcO29 CU82045 CC82967 Co2734 ¢CC8181S CcO81821 cOR1826 COPIRS? CORT°2S cORZ79R CORD132 
CurI9ué CuRz92e CORZ0GC €081919 COB2034 CCB8Z035 COB206R  CORZT13-R. CORIP7A €OF194N-B COR2Z042 081928 
cuezic?  CcR1885 CuR1887 CO81R93 COR2Z027 CoRC7S57 cOBITSO CCB1790 CORIR1® CORIASM CORIRSS COR1865 
CUE 1866 CU61896 CG81945 cu82006 CO8 2046 €u81779 ,€082122 CC82002 COR WES €081926 COR2MBR-B CC#2090 
Cufiz1zZ«— CUFIGGS® «= COR2787-R COB2270 €381999 CC82017 Ccb81804 CLR2049 cOR2MSR cOR1RO* FOF1926 ©€ 082032 
CURZC74 «= CL819G7? = «CO81760 «= CUR185S = C082014 =—CO82098 §«=—c0R 2156 «= 81765 «= COR 1270 «= COR1750 «= OR 1809 = € 08 1883 
CURZ2. = Cua2064 «= CURZIS2 «= COBZ2Z4 «= CO82271 = CCB 1710 »=—s C08 1780 )=—s C68 19G2 «COR 178% «= 089757 = OR 1FS2 = 081690 
CUFIFS® CGRI776 «©—- CUB 1869 = C0B81917 = C08 2005-B C681916 ~=— 081929 CLRZ093 = CORZ1ZH6. «= CORINNGS «= CORSA «=. 2.810 
COFZNG* CORZI3E COB2074 «= cG81824 = COBCO8D = CB 2043 = OR2057 «= CUB2072. Ss COR20S& «= COAZNBO = C0R2031 ~=—s 08 2873 
CLEI942 CCRZOU? COF18B4 CO82058-E €082059 CC81775 COf1827 CiB81269 CORRS?  ¢€OR1892 COR2ZN3N ¢c081798 
CUFIKG? «= CLRIBSE «= CLA2026 = CUB2D27 = COB 2022 «= CCB 2047 «= C08 1863 = CC#2N19 «= cOR2920 «082057 082052 = SMOBA 
BACKUP -1 CU2z0S2 (O80576 MESCER-I X460-OC-1 N6OOC-10-1 K6fO-20-1 x60U-30-1 X6PO-SA-Y X6NO-60-F K600-89-1¥ x700-00-1 
MBCi-“CO-1 4 12C-OO-1 €4130-02-1 €201-00-1 6201-03-1 6210-00-1 6211-00-1 6212-CO-1 6273-ON-1 &214-O0-1F 6295-O0N-2 6216-00-1 
6217-0%-1 6218-UO-¥ €219-GO-1 6220-UC-1 &229-OC-1 6222-00-I &222-01-1 &223-00-1 6224-ON-1 6225-OC-1 &226-QN-1 6278-00-! 
622$-C1-1 6229-02-13 &229-03-1 6230-00-1 6231-09-1 6232-O%-1 6233-GI-1 6247-UC-1 6247-01-1 6247-02-Y 6248-ON-¥ 6748-01-1 
6248-U2-1 O24-G3-1 E248-G4-1 6268-05~1 6248-06-1 6248-07-1 6254-09-1 6255-00-1 CORIE5%  COR2150 





LEI 


Figure 13-2. Sample of Condensed SMC Listing 
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Section 14 
Diskette Copy Routine (SUSCPY) 


The diskette copy routine (SU$CPY) can generate up to three copies of an 8420 
diskette, whether it is data set label or format label, single or double density. The 
SU$CPY routine also gives you the option of verifying individual 8420 diskettes once 
you've copied them. All you have to do to execute SU$CPY is key in a simple command 
at the system console or workstation. Once you've entered this command, a series of 
messages appear on the screen requesting you to select certain options. 


14.1. Executing SUSCPY 


Mount the diskette you are copying (input) in a drive with a lower device-id number 
than the output diskette’s drive. 


The format of the command used to execute SU$CPY is 


© RV ie 1 
2 


3 
where: 


tl 


Specifies the number of copies you’re making. 


During the execution of the SU$CPY routine, you are asked to reply to the following 
messages: 


Message 1 
JJi=NUMBER OF COPIES REQUIRED OF OUTPUT 2,3 DEFAULT=1 

Reply 
Press the XMIT key to default to the number of copies you originally requested in 
the RV SU$CPY command. If you want to change the number of copies you 
originally requested, enter the job number and message-id (jji) and then the 
number of the copies wanted (1, 2, or 3). Press the XMIT key. The number 


specified overrides the one that was originally specified in the RV SU$CPY 
command. Message 2 appears on the screen after you transmit your reply. 
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Message 2 


JjJi=TYPE OF OPERATION: COPY, VERIFY 


Reply 


You should reply by entering the job number and message-id and one of the 
following specifications: 


If no reply is given to this message and you press the XMIT key, the C option is 
assumed and message 3 appears on the screen. 


Message 3 


c 
Indicates that you are making copies. 


Indicates that you are verifying a diskette. 





JJi=N=NEXT DISKETTE MOUNTED OR DEFAULT=FINAL DISKETTE 


Reply 


If more diskettes are to be copied, remove the current diskette, mount the next 
diskette to be copied, and reply by keying in N along with the job number and 





message-id. This resumes the message sequence starting at message 2. 


To terminate the job, press the XMIT key instead of replying to the message. 


If you want to verify a copy, key in the N parameter and press XMIT. This 
resumes the message sequence starting at message 2. Then you can simply key in 
V and press the XMIT key to verify the copy. After verification, message 3 again 
appears on the screen. 


Note: 


142 


Only one diskette can be verified each time you execute SU$CPY. So, if you are 
making more than one copy in a single execution of SU$CPY, only the first copy 
can be verified. To verify the remaining copies, you must run separate SU$CPY 
operations using the V (verify) option for each individual copy. 
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14.2. Programming Examples 


The following are examples of ayeeem console listings showing the execution of the 
SU$CPY routine: 





Example 1: Diskette Copy 
1. | RV SUSCPY 
2. SUSCPY (2) (3) (4) (5) (6) (7) 
3. | 1L JC@B8 USING DEV=FFF TYPE=PRNTR 
4. | IM*JC@9 MOUNT DEV=32@ VSN=IN DEV=321 VSN=OUT G0? 
5. | GO SUSCPY 
6. | 1N JC@1 JOB SUSCPY EXECUTING JOB STEP SUSCPY@0 #001 
7. | 1P?NUMBER OF COPIES REQUIRED OF OUTPUT 2,3 DEFAULT=1 
8. | 1P 
9. | Q? TYPE OF OPERATION: COPY,VERIFY 
10.| 10 
11.) 1A2N=NEXT DISKETTE MOUNTED OR DEFAULT=FINAL DISKETTE 
12.| 1A 
1B END OF STANDALONE COPY ROUTINE 
(1) (2) (3) (4) (5) (6) (7) 
1C JC@2 JOB SUSCPY = TERMINATED NORMALLY 
BR CN 


Here, you are making a single copy of an 8420 diskette. The RV SU$CPY command on 
line 1 executes the SU$CPY routine, and line 2 shows the job slot in which the copy 
routine is running. Note that no N= specification is given in the RV SU$CPY 
command to specify the number of output copies. Since no number is specified, the 
default of 1 is used. 


The next four lines (lines 3, 4, 5, and 6) are messages showing the devices being used 
and indicating the start of the routine’s execution message sequence. The message in 
line 7 is the first message of the sequence. It requests you to enter the number of 

output copies. In this example, no reply is given in line 8 and the default of 1 is used. 


The XMIT key is then pressed and the message in line 9 appears requesting you to 
specify either C (for copy) or V (for verify). In line 10, no reply is given and the XMIT 
key is pressed. This causes the default C to be initiated. The diskette is then copied 
and the next request message is generated in line 11. 


The final message of the sequence (line 11) requests you to either mount another 
diskette, generate another TYPE OF MESSAGE request (line 9), or terminate the job. 
Here, because no further copying or verifying is desired, nothing is entered in line 12 
and the XMIT key is pressed, initiating the default and terminating the job. 
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Example 2: Diskette Verify 
1. [RV SUSCPY 
2. | suscpy (2) (3) (4) (5) (6) (7) 
3. |1€ JC@B USING DEV=FFF TYPE=PRNTR 
4. |1F*JC@9 MOUNT DEV=32@ VSN=IN DEV=321 VSN=OUT GO? 
5. |GO SUSCPY 
6. |1G JC@1 JOB SUSCPY EXECUTING JOB STEP SUSCPYOé #001 
7. | 1H?NUMBER OF ;COPIES ; REQUIRED; OF ;OUTPUT ;2,3;DEFAULT=1 
8. | 1H 
9. |1J2 TYPE OF OPERATION: COPY,VERIFY 
10.) 1d;V : . 
11. | 1K2N=NEXT DISKETTE MOUNTED OR DEFAULT=FINAL DISKETTE 
12.| 1k 
1 END OF STANDALONE COPY ROUTINE 
(1) (2) (3) (4) (5) (6) (7) 
1M JC@2 JOB SUSCPY TERMINATED NORMALLY 
BR CN 


The console listing in this example is exactly the same as the one shown in the 
diskette copy operation in Example 1. However, because this is a verify operation, the 
reply to the TYPE OF OPERATION request (line 9) is V (for verify). This reply is 
shown in line 10. 


Example 3: Diskette Copy and Verify 


5. 





RV SUSCPY 
SUSCPY (2) (3) (4) (5) (6) (7) 
1Q JCO@8 USING DEV=FFF TYPE=PRNTR 
1A*JC@9 MOUNT DEV=320 VSN=IN DEV=321 VSN=OUT GO? 
GO SUSCPY 


1B JC@1 JOB SUSCPY EXECUTING JOB STEP SUSCPY@@ #001 
1C?NUMBER OF COPIES REQUIRED OF OUTPUT 2,3 DEFAULT=1 


1c 
10? TYPE OF OPERATION: COPY,VERIFY 
10 
1E?N=NEXT DISKETTE MOUNTED OR DEFAULT=FINAL DISKETTE 
1E N 
1F2? TYPE OF OPERATION: COPY,VERIFY 
FV 
G?N=NEXT DISKETTE MOUNTED OR DEFAULT=FINAL DISKETTE 
1G 
1H END OF STANDALONE COPY ROUTINE 
(1) (2) (3) (4) (5) (6) (7) 
1J JC@2 JOB SUSCPY TERMINATED NORMALLY 
BR CN 
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Example 3 is similar to the diskette copy operation in Example 1. Here, however, a 
copy and verify operation is performed in the same execution. The first part of the 
control stream (lines 1 through 10) performs the diskette copy. 


The difference between this example and Example 1 begins in line 11 with the request 
to either mount another output disk, generate a TYPE OF OPERATION request, or 
terminate the job. In this example, the letter N is keyed in and the XMIT key is 
pressed (line 12). This generates another TYPE OF OPERATION request as shown in 
line 13. 


In line 14, a reply of V (for verify) is entered and the XMIT key is pressed. This 
verifies the same output disk that was created in the copy operation and generates the 
message shown in line 15. 


Since no further copies are being made or verified, the default is used as the reply to 
this message (line 16), the XMIT key is pressed and the job is terminated. 
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Section 15 
System Utility Copy Routines 


15.1. 8419 Disk Copying (SUSC19) 


Use the SU$C19 disk copy routine to simultaneously create and verify up to six copies 
of a single 8419 disk, regardless of the disk’s contents. The verification procedure 
ensures that your disk was copied correctly by comparing the contents of the input 
with that of the output. You can also use the SU$C19 routine in a separate operation 
to verify copies that were made by a previous SU$C19 copy operation or a disk copy 
operation performed using the dump/restore routine. You can execute the SU$C19 
routine either interactively from a workstation or in a batch environment. Either 
method achieves the same results; however, the interactive method is easier to use. 


15.1.1. Executing SUSC19 in an Interactive Environment 


Interactive processing of the SU$C19 routine consists of a question and answer 
session (dialog). Before executing SU$C19, you must have successfully logged on to 
the system via the LOGON command. After logging on, key in HU in system mode 
and press the XMIT key. After pressing the XMIT key, a menu screen appears. 


HARDWARE UTILITIES 


. DUMP FILES FROM A DISK 

- RESTORE FILES TO A DISK 

. LIST FILES ON A BACKUP MEDIUM 

- COPY FILES FROM DISK TO DISK 

. COPY AND/OR VERIFY 8419 DISK 

« COPY AND/OR VERIFY 8416/8418 DISK 
- COPY AND/OR VERIFY 8430/8433 DISK 
- NONE OF THESE 


1 
2 
3 
4 
5 
6 
7 
8 


ENTER SELECTION 





Note: Selections 6 and 7 are applicable only to model 8 through 20 systems and do 
not appear in the menu screen (HUOOA) displayed on model 3 through 6 
systems. 
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Select 5 from the menu screen to start the execution of the SU$C19 routine. After 
pressing XMIT, the following informational message screen appears: 


HU@@BI 03 
A CONVERSATIONAL JOB (HUSCPY) TO COPY FILES FROM ONE DISK TO 
ANOTHER WILL BE INITIATED IN YOUR BEHALF. YOU MUST BE IN SYSTEM 
MODE FOR THE JOB TO BE SCHEDULED. IF YOU ENTERED HARDWARE 


UTILITIES THROUGH THE HU COMMAND YOU WILL BE IN SYSTEM MODE 
AFTER TRANSMITTING. IF YOU ENTERED THROUGH THE MENU COMMAND YOU 
ARE RESPONSIBLE FOR GOING INTO SYSTEM MODE. 

wekee TRANSMIT TO CONTINUE 9 ***** 





After reading the message screen indicating that a copy job was initiated, press XMIT. 
Screen 1 is displayed. 


Screen 1 (HU13): Number of Copies, Starting/Ending Addresses, and Verification Option © 


COPY- VERIFY 
COPIES - UP TO 6 copy=4 


BEGIN ADDRESS (CCC) Bcap=000 





END ADDRESS (CCC) EDAD=808 
ONLY VERIFY over=fq 


eeeeweee FUNCTION KEYS: FIZ=HELP, FIG=EXIT HELP ******** 





Looking at screen 1, we used the default 1 for the number of copies, took the default 
for the beginning and ending addresses (cylinder 000 for beginning and 808 for 
ending), and entered NO indicating that we are in a “copy” operation and not a “verify- 
only” operation. Since help is not required, press XMIT. 


Screen 2 (HU14): File Options 


HU14 


UNEXPIRED FILE CHECKING UNXF=YES 


VERIFY veFY=pg 


weweeee FUNCTION KEYS: FIS=HELP,F14=EXIT HELP ****#8e% 
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On this screen, we want to enter unexpired file checking and output verification. The 
unexpired file checking (UNXF=YES, default) checks the output volume for file 
expiration dates. If the date has not expired, a message is displayed in system mode of 
the workstation asking you to either skip the file and continue processing or 
terminate. Up to 10 files at a time can be skipped. (The expiration option must not be 
used with unprepped output disk packs. To do so results in a space management 
error.) We specified VEFY=YES for file verification (overriding the default). 
Verification ensures that an exact copy of your input is produced. Any errors detected 
will be printed using the print option (next screen). 


Screen 3 (HU15): Print Option 


COPY-VERIFY HU15 


PRINT ALL ERRORS PRNT=YES 





Since we specified the verify option on the last screen, we recommend that you take 
the default YES to print any errors detected during the copy process. Press XMIT. 


Screen 4 (HUO]1): Input and Output Device Information 


COPY INPUT-OUTPUT DEVICE INFORMATION 
ENTER INPUT VOLUME SERIAL NUMBER: 


ENTER OUTPUT VOLUME SERIAL NUMBERS 
DQQ412 


Here, we enter our volume serial numbers (DISKIN for INPUT and DISK01, DISK02, 
and DISKO03 for three copies of our output). Press XMIT to complete the copy 
operation. After pressing XMIT, the workstation becomes free for other uses and the 
HU25 HARDWARE UTILITIES information screen appears. 





HARDWARE UTILITIES HU25 
THE INTERACTIVE INTERFACE FOR THIS PROGRAM 


HAS NOW BEEN COMPLETED. THIS WORKSTATION WILL BE 
AVAILABE FOR USE WHILE THE PROGRAM PROCESSES AS 
YOU REQUESTED. 





When the job is finished, an end-of-job message is displayed on our workstation 
screen, showing the parameter selected and the UPSI byte setting. If the setting is 
other than X‘00’, errors occurred and are reported. 
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15.1.2. 


15-4 


**®*SYSTEM UTILITY COPY ROUTINE FOR DISKS 8419 **** xxee ae 


// PARAM COPY=1,8GAD=00@ , EDAD=898 , OVEF=NO, UNXF=YES, VEFY=YES 


SC5@ UPSI SETTING X'@O! 





Note: After copying, our output volume serial number is the same as our input volume 
serial number (REL 120). If we want the original serial number (D00410), then 
we can execute the CGV canned control stream to change the volume serial 
number (see Section 9). 


Executing SUSC19 in a Batch Environment 
When executing SU$C19 in a batch environment, you must supply the appropriate job 


control statements defining your devices. All the options available to you in an 
interactive environment are supported in batch. 


SUSC19 Organization 

SU$C19 has seven parameters that control its operation. All of them have default 
values and are associated with the // PARAM statement. If you choose all the defaults, 
however, omit the // PARAM statement from your control stream. 


The format of the SU$C19 // PARAM statement is 
,VEFY= te PRNT= { NO ,OVEF= ie } ,BGAD= { ccc 
} YES YES YES 000 } 


,EDAD= {ccc | UNXF= va} 
NO 


Use the COPY parameter to indicate how many copies of your input disk are to be 
made or verified when using the OVEF parameter. The value of n may vary from 1 
to 6. If you omit the COPY parameter, one copy is specified by default. 


n 


/1 PARAM | COPY= | 

















Use the VEFY parameter in conjunction with the COPY parameter to verify the 
contents of each new output disk. If you specify VEFY=YES, each copy is verified 
against the input. If you omit the VEFY parameter, no verification is performed. 


Use the PRNT parameter to print any incorrect records found during verification. If 
an error is detected, both the input and output records are listed with their 
corresponding disk address. A sample verification printout, showing input and output 
records, is shown in Figure 15-1. If you omit the PRNT parameter, messages are 
displayed on the system console, instead of the printer. 
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COMPARE ERROR OW OISC ts) CYLINDER NUMBER onca WEAD AOORESS ocoo RECORD mINBER ooa2 

PRINT OUT OF INPUT FILE 
0$0505DS 000700C90005 s002Sn0000 CODOLAONDONNADCOOOOrOCOCoD COOCOOCON CO COCGOOOC CO OOO DO OOO OOF SaccoCcone tC cococ cece coc 
Socoosveacceccoco occ cooconsccG OODOLOCL VOCCOODOG0C DOC OCCOLOUCLEC00500 CO 00GCO0LO 0nd DODOC ooo CoOOO CCOND CooNDCcNNnE Coo 
000039000900000939 009000000000) DOD DONCSCoNCGICOGOO COC O0NNIING OC OOO NNN ECL00000L0 G00 DoODNOEO CONDO DOCOaCcoDCDanONN CoO 
CODOsIGOCOONOIOOOOOHOCOLODNCOI ADDOC OCH COCOHOLNOCOCOCOOC OONON ClLNC OGO cOCoOoCOCO OOD COON OOo CONN CONC a coeooN00NN CaO 
000009 00 005000000000 OCOdan0 NNN COLOODUOONOcCOONOCOOOrCOOCONnoe Cooo 

PRINT OUT OF OUTPUT FILE 
OS5S0S05 0SCCOTO0C S0OCDGCCCCOO ODO COOOL OCCUCC CC DOC OGruOcICNQOCOCICONN Oo COCOLCEOOOL OU DOGOCCOF SONoOCroCOCoCOOoCcoeNO (oo 
CroooddoecoooIGIoCOoCUCLCoON OOD cosoc oceoccoonoDeNsccrcecoseco cecooc oc cOccCCOCcOC OO OQOcOOoCONL vO OCHO co OOOCOrUacOO coc 
Goon IOocIITOIOSOGOOCreCocooOON OOCeCILCuICCEODOCOCoCONceCCoNor coOLCoC OO COodUceCcCocooCooGoocooaooCC OcCod oGDOrcooca coc 
GaocsoooooocooNCoNNS COLOccOONN OOS Oca IOGIG roodonVONCOCOICear OO LOCOOC Co Crono nd OLO Coo ODndCaODOoOGe CConaccoancoces coo 
Eebiletelelefelefetefelelelorelatelatelebetel a elelaoseleieneiezelsleretelsd rletegel:fel eel terete: Laielieletlefebab eaves 

COMPARE ERROR ON DISC e CYLINDER NUMBER c7ca MEAD SODRESS oco0 RECORD WURBER coos 

PRINT OUT OF INPUT FILE 
60Ca3900080099993003CO0CONG DOI Ce SOCOCC OC ICOOOOOOOCONGCOCSoDOr Wooo IS cocCorcoocooceccoronoo oes condo cocoon DODONNDNCO Coe 
GogacoboCoVDDNONO DON GCOGCGCoONr COS OODNGGOCCOOGoONCOOL CODDUCOL CaocoOr on CCoOoCOCKOCCaCoDOcaOOOODNOCHOODO COO OONCNCS CoO 
Goode cCoNanoDOSO DOr CCOnG 30000 Coc oCOUC OEE COoCDNrC Coron acon oocaLoCor Go Lorde cococ aoc ocooococooccoccoocccoococccacoe 
Oogg0tCGONC COOrO ORD GCC O000 Don CoO OCoOCONCOOCOCCOGOOoCCOC Ce OOLOC O0CuO CocoGcon uo unc CooDoCcooLoCoNccooe cooccoooco coc 


00003300000000003 000 000c0 00002 ceoNcoanaCoDSOCOONCoOoOSNONCNN COON 


é PRINT OUT OF OUTPUT FILE 
OGcagcdo0 70000000000 CoL000N CNN COD ODDEN DCOCCODGOOVON0N D0000 08 LOLOUC Co Conone 0L0OC0 DDoS OOroNOOOocroOL Cooocooses coc 
ecue0eboco00 c0000 000 cecca00 200 no cpUOCD OO COO OUD OOOCOeLOVDGE COCCOOLG COCOOOOCCODOaODOONOOODOOOCCUOCCCeCECEOOO CCE 
Dooce oCeoGOGON CON COCC CON DN0 CDG ONCEC ODO COONCROUNOSONOOONCO CrocooLOCoceCcoCc uo coc coDOcoCOCcOcoccooc tcooraosco coo 
soocadboosocoooc0 000 0c 00020 con 00 DoDoDD OND PODODODaLONCNLrOSOO COoDNt cD cOoc0000%00 Coo cocor oO OONNE cocoorcooeccnos 000 
G00039000000030900000000003009 oJua000000000000000C0000NNNGON CD0L 





Figure 15-1. Sample Verification Printer Output 


Use the OVEF parameter to indicate a verify-only operation is performed on an 
output disk created by a previous copy operation. When OVEF=YES is specified, no 
copies are made. However, the COPY parameter or its default is used to indicate the 
number of output disk volumes being verified. The OVEF parameter may be used in 
conjunction with the BGAD and EDAD parameters, but cannot be specified if 
VEFY=YES is specified in the same control stream. The default of the OVEF 
parameter is NO. 


Use the BGAD parameter to indicate the beginning cylinder address, in decimal, for 
duplication or verification. The address you specify must be the cylinder number (ccc). 
If you omit the BGAD parameter, the beginning address is cylinder 000. 


Use the EDAD parameter to indicate the ending cylinder address, in decimal, for 


duplication or verification. The address you specify must be the cylinder number (ccc). 
If you omit the EDAD parameter, the ending address is 808. 
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Use the UNXF parameter to check for the file expiration date. If the file date has not 
expired, a message is displayed asking you either to continue processing or to skip the 
file and continue to the next file (providing you are processing more than one file). 
Using the UNXF parameter eliminates the time and expense of keeping outdated files 
and also eliminates the overlaying of files that should not be destroyed. 


Note: The SU$C19 program will not allow you to copy less than one cylinder of data. 


SUSC19 Interfacing with Job Control 


Specify DISCIN on the // LFD job control statement for your input disk, and DISCOT 
on the // LFD job control statement for your output disk. If you are copying onto more 
than one disk, DISCOT01 through DISCOT05 must be specified for each disk, 
following the first one. 


Programming Examples 
The following control streams show some typical examples of how to use SU$C19: 
Example I 


// JOB STDCOPY 

// DVC 58 // VOL DSK@Q1 // LFD DISCIN 
// DVC 51 // VOL DSK@@2 // LFO DISCOT 
// EXEC su$c19 

/& 

// FIN 


This is a basic 8419 disk copy operation with no verification. Since no printer is 
specified in your device assignments, no printer output is available. Notice that, since 
no parameters are specified, the // PARAM statement is omitted from your control 
stream. Here, a single copy is made. 


Example 2 


// JOB VFYCOPY 

// DVC 5@ // VOL DSK@@1 // LFD DISCIN 
// DVC 51 // VOL DSKO@2 // LFD DISCOT 
// DVC 28 // LFD PRNTR 

// EXEC SU$C19 

// PARAM VEFY=YES,PRNT=YES 

1& 

// FIN 


This is an 8419 disk copy operation with verification. Since you are using the print 
option (PRNT=YES), the device assignment set for the printer must be specified. The 
file name PRNTR must appear in the // LFD statement for the printer. If you specify 
verification (VEFY=YES) and do not specify a printer, your job is executed, but errors 
are displayed on the system console. 
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Example 3 


// JOB COPYSIX 

// DVC 5@ // VOL DSK@Q@ // LFD DISCIN 
// DVC 51 // VOL DSK@@1 // LFD DISCOT 
// OVC 52 // VOL DSK@@2 // LFD DISCOT®1 
// DVC 53 // VOL DSK@@3 // LFD DISCOT@2 
// OVC 54 // VOL DSK@Q4 // LFD DISCOT@3 
// OVC 55 // VOL DSK@@5 // LFD DISCOTO4 
// OVC 56 // VOL DSK@@6 // LFD DISCOT@S 
// DVC 20 // LFD PRNTR 

// EXEC susCc19 

// PARAM COPY=6, VEFY=YES, PRNT=YES ,UNXF=YES 
/& 

// FIN 


Here, you are copying an 8419 input disk to six 8419 output disks with verification, 
printing, and file expiration date checking. Note the required file names (DISCOT 
through DISCOT05) specified on the // LFD job control statements. 


15.2. 8416/8418 Disk Copying (SUSC16) 


Use the SU$C16 disk copy routine to simultaneously create and optionally verify up to 
seven copies of a single 8416 or 8418 disk, regardless of the disk’s contents. The 
verification process ensures that your disk was copied correctly by comparing the 
contents of the input with that of the output. You can use this routine in a separate 
operation to verify copies that were made by a previous SU$C16 disk copy operation 
or a disk copy operation using the dump/restore routine. 


You can execute the SU$C16 routine either interactively from a workstation or in a 
batch environment. Both methods achieve the same results. 


15.2.1. Executing SUSC16 in an Interactive Environment 


Interactive processing of the SU$FC16 routine consists of a question and answer 
session (dialog). Before executing SU$C16, you must have successfully logged on to 
the system via the LOGON command. After logging on, key in HU in system mode 
and press XMIT. After pressing XMIT, the following menu screen appears: 


UP-8841 Rev. 4 15-7 





System Utility Copy Routines 


158 





HARDWARE UTILITIES 


DUMP FILES FROM A DISK 

RESTORE FILES TO A DISK 

LIST FILES ON A BACKUP MEDIUM 
COPY FILES FROM DISK TO DISK 

COPY AND/OR VERIFY 8419 DISK 

COPY AND/OR VERIFY 8416/8418 DISK 
COPY AND/OR VERIFY 8430/8433 DISK 
NONE OF THESE 


ENTER SELECTION 





Select 5 from the menu screen to start execution of the SU$C16 routine 


After pressing XMIT, the following HU00CI05 information screen is displayed: 


HU80C1@5 


A CONVERSATIONAL JOB (HU$C16) TO COPY THE CONTENTS OF ONE 8416/ 
8418 DISK TO ONE OR MORE DISKS OR TO VERIFY THE CONTENTS OF ONE 
OR MORE DISKS HAS BEEN INITIATED IN YOUR BEHALF. YOU MUST BE 
IN SYSTEM MODE FOR THE JOB TO BE SCHEDULED. IF YOU ENTERED 
HARDWARE UTILITIES THROUGH THE HU COMMAND YOU WILL BE IN SYSTEM 
MODE AFTER TRANSMITTING. IF YOU ENTERED THROUGH THE MENU 
COMMAND YOU ARE RESPONSIBLE FOR GOING INTO SYSTEM MODE. 





*weeee TRANSMIT TO CONTINUE ***** 





After reading the message screen indicating that a copy job was initiated, press XMIT. 
The following screen appears: 


Screen 1 (HUO9): Indicating the Disk Device Type and Volume Serial Number 


COPY INPUT DEVICE INFORMATION 


ENTER SPECIFIC DISK DEVICE TYPE: 


ENTER VOLUME SERIAL NUMBER: [Perro 


wikkeeee FUNCTION KEYS: F13=HELP, FI4=EXIT HELP ******** 
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Looking at Screen 1, we entered 8416 for the disk device type and 123456 for the 
volume serial number. The device type entered on this screen must be one of two 
disks: 8416 or 8418. 


Note: Regarding the screens, all the default values are shaded while the user entries 
are shown in reverse lettering (white characters on black background). 


Since help is not required, press XMIT and the following screen appears: 


Screen 2 (HU13): Indicating Number of Copies, Begin/End Addresses, and Verification Option 


COPY-VERIFY HU13 


COPIES - UP TO 7 cOPY= 


BEGIN ADDRESS (CCC) BGAD=008 
END ADDRESS (CCC) EDAD=193 
ONLY VERIFY OVEF=NO 


WRERRERE FUNCTION KEYS: FI3=HELP, FIG=EXIT HELP **eeeee 





Looking at Screen 2, we entered 3 for the number of copies (overriding the default of 
1). We took the default values, which appear on the screen, for the beginning and 
ending addresses (cylinder 000 for beginning and 193 for ending), as well as the 
default option NO, indicating that we are doing a “copy” operation and not a “verify- 
only” operation. Since help is not required, press XMIT. 


Screen 3 (HU14): Indicating the File Options 






COPY 






HU14 


UNEXPIRED FILE CHECKING UNXF=YES 


VERIFY very =f 


keaKKEER EYNCTION KEYS: 









FI3Z=HELP, FIGSEXIT HELP ****eeew 





On this screen, we want unexpired file checking and output verification. We entered 
YES for output verification and allowed the unexpired file checking option (UNXF) to 
default to YES. Unexpired file checking checks the output volume for file expiration 
dates. If the date has not expired and your workstation is in system mode, your screen 
displays a message. This message asks you either to terminate or to skip the file and 
continue processing. You can skip up to 10 files at a time. (The expiration option must 
not be used with unprepped output disk packs. To do so results in a space 
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management error.) Verification ensures that an exact copy of your input is produced. 
Any errors detected are printed by using the print option (next screen). 


Screen 4 (HU15): Indicating the Print Option 


COPY-VERIFY HU15 


PRINT ALL ERRORS PRNT=YES 





Since we specified the verify option on the last screen, we recommend that you take 
the default YES to print any errors detected during the copy process. Press XMIT. 


Screen 5 (HU11): Specifying Output Device Information 


COPY OUTPUT DEVICE INFORMATION 





ENTER SPECIFIC DISK DEVICE TYPE: (igre 


ENTER VOLUME SERIAL NUMBER(S): 


DISK@1 DISKO2 ES @B) 





wee FUNCTION KEYS: FI3=HELP, FIGSEXIT HELP **#8*##® 





On this screen, we entered 8416 as our output disk device type. Next, we entered our 
output volume serial numbers. The number of underscored input fields requesting 
volume serial numbers that appear on the screen are equal to the number of copies 
specified on Screen 2 (HU13). All fields that appear must be filled in. Since we 
specified three copies, fields for three volume serial numbers appear on the screen. We 
entered volume serial numbers DISK01, DISK02, and DISKO3 for the three copies of 
our output. Press XMIT to complete the copy operation. After you press XMIT, the 
workstation becomes free for other uses and the following HU25 screen appears. 
When the job is finished, your workstation screen displays an end-of-job message. 









HARDWARE UTILITIES 








THE INTERACTIVE INTERFACE FOR THIS PROGRAM 
HAS NOW BEEN COMPLETED. THIS WORKSTATION WILL BE 
AVAILABLE FOR USE WHILE THE PROGRAM PROCESSES AS 
YOU REQUESTED. 
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15.2.2. Executing SUSC16 in a Batch Environment 


When executing SU$C16 in a batch environment, you must supply the appropriate job 
control statements defining your devices. All the options available to you in an 
interactive environment are supported in batch. 


SUSC16 Organization 


SU$C16 has seven parameters that control its operation. All these parameters have 
default values and are associated with the // PARAM statement. However, if you 
choose all of the defaults, you must still have the // PARAM statement present in your 
control stream. 


The format of SU$C16 is 


vee 





fae eet 


, 8GAD= CCC 4, ,EDAD= CCC ae ,UNXF ={NO 
cechy, cecha, 4 YES 
cechrr 44 





ih \ for 8416 and 8418 Low 
27628 for 8418 high 





Use the COPY parameter to indicate how many copies of your input disk pack are to be 
made. The value of n may be from 1 to 7. If you omit COPY, one copy is made. 


Use the VEFY parameter to verify your new output. If VEFY=YES is specified, each copy is 
verified against the input. If you omit VEFY, then no verification is performed. 


Use the PRNT parameter to print any records found to be in error. If an error is detected, 
both the input and output records are listed with its corresponding output disk address 
(ccchrr) in hexadecimal. You would normally choose PRNT=YES if you had chosen 
VEFY=YES. If you omit PRNT, only fatal errors are written on the system console. 


Use the BGAD parameter to indicate the starting address of your copy in hexadecimal. The 
address may be a cylinder number (ccc,,), a cylinder/head number (ccch,,), or a 
cylinder/head/record number (ccchrr,,). If you omit BGAD, the beginning address is 
cylinder 000, head 0, and record 01. 


Use the OVEF parameter to indicate that a verify-only operation is to be performed. No 
copy will be made. If you omit OVEF, one or more copies will be made, with or without 
specification, depending on other parameter specifications. OVEF may be used in 
conjunction with BGAD and EDAD. 
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Use the EDAD parameter to indicate the ending address of your copy in hexadecimal © 
(cecy,, ccch,,, or ccchrr,,). If you omit EDAD, the default values for the hexadecimal ending 


addresses are as follows: 


Disk Subsystem Cylinder Head Record 
8416 193 6 28 
8418 low 193 6 28 
8418 high 327 6 28 


By using both the BGAD and EDAD parameters, you can copy only one record from your 
input pack to your output pack. It is worth remembering that the input starting and 
ending addresses are the same as your output addresses, and any information contained in 
your specified output area is destroyed and the new information is written in that area. For 
example, if you were copying from cylinders 10 through 20, any information residing in 
cylinders 10 through 20 in your output pack is destroyed and the new information is 
written in that area. 


Use the UNXF parameter to check for the file expiration date of any file on the output 
disks. If the file date has not expired, a message is displayed that asks you either to 
continue processing or to skip the file and continue to the next file (providing you are 
processing more than one file). Using the UNXF parameter eliminates the time and 
expense of keeping outdated files. It also eliminates the overlaying of files that should not 
be destroyed. 





SUSC16 Interfacing with Job Control 


The file name DISCIN must be specified on the // LFD job control statement for your input 
disk pack. The file name DISCOT must be specified on the // LFD job control statement for 
your output disk pack. If you are copying onto more than one disk pack, DISCOTO1 
through DISCOT06 must be specified for each disk pack being copied. 


Executing SUSC16 


In a multijob environment, the use of SU$C16 can cause space allocated to a file to be lost; 
files may be added to or portions deleted, or a disk pack may be incorrectly copied. These 
situations can occur when another job is updating the VTOC of a disk pack at the same 
time SU$C16 is copying that VTOC to another disk pack, or when SU$C16 is copying a file 
while another job is extending or scratching that file. Therefore, the job executing SU$C16 
must be the only job running when the I/O device is either SYSRUN or SYSRES. If the 
device is not SYSRUN or SYSRES, it must be set to nonshareable by the operator. This 
ensures that an exact copy will be made by SU$C16. 
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Programming Examples 
The following control streams show some typical examples of how to use SU$C16: 
Example 1 


1 18 16 72 





// SOB STDOCOPY 

// DVC 60 // VOL DSP@@1 // LFD DISCIN 
// DVC 61 // VOL DSP@@2 // LFD DISCOT 
// EXEC SU$C16 

// PARAM 

i: 

// FIN 


Note that even though you did not specify any parameters, the // PARAM statement 
still appears in your control stream. This is the basic disk copy operation. The printer 
is not specified; therefore, no printer output is available. 


Example 2 


1 18 16 72 





// SOB VPCOPY 
// OVC 58 // VOL DSP@O1 // LFD DISCIN 


// OVC 51 // VOL DSP@@2 // LFD DISCOT 
// DVC 20 // LFD PRNTR 

// EXEC SU$C16 

// PARAM VEFY=YES,PRNT=YES 

1k 

// FIN 


Since you are using the print option, the device assignment set for the printer must be 
specified. The file name PRNTR must be specified on the // LFD job control statement. 
The verification and printing are specified. If you do not specify a printer, your job is 
executed but only fatal errors detected are displayed on the system console. 
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Example 3 





// JOB COPY7 

// DVC 5@ // VOL DSP@@1 // LFD DISCIN 
// OVC 51 // VOL DSP@82 // LFD DISCOT 
// OVC 52 // VOL DSPO@3 // LFD DISCOT@1 
// OVC 53 // VOL DSPOG4 // LFD DISCOT@2 
// DVC 54 // VOL DSP@O5 // LFD DISCOTO3 
// OVC 55 // VOL DSP®G6 // LFD DISCOTO4 
// DVC 56 // VOL DSPOO7 // LFD DISCOT@5 
// DVC 57 // VOL DSP@Q8 // LFD DISCOTG6 
// DVC 20 // LFD PRNTR 

// EXEC SUSC16 

// PARAM COPY=7,VEFY=YES, PRNT=YES,UNXF=YES 
/® 

// FIN 


Here, you are copying your input disk pack to seven output packs with verification, 
printing, and file expiration date checking. Note the required file names specified on 
the // LFD job control statements. 


Example 4 
1 1016 72 @ 


// JOB COPYTRK 

// DVC 20 // PRNTR 

// DVC 68 // VOL DSP@@1 // LFD DISCIN 

// OVC 61 // VOL DSPOO2 // LFD DISCOT 

// OVC 62 // VOL DSP@@3 // LFD DISCOTO1 

// EXEC susclé6 

// PARAM COPY=2,BGAD=0054 , EDAD=0054 , VEFY=YES 
/& 

// FIN 








This example makes two copies of one track and verifies the copies. There is no 
printer output and verification of the output is written to the console. 
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1 16 16 72 





// JOB COPYCYL 

// DVC 68 // VOL DSP@B1 // LFD DISCIN 
// DVC 61 // VOL DSP@@2 // LFD DISCOT 
// EXEC Su$c16 

// PARAM BGAD@=7A,EDAD=07A 

/& 

// FIN 


This example makes one copy of one cylinder. There is no printer output and no 
verification. 


15.3. 8430/8433 Disk Copying (SUSCSL) 


Use the SU$CSL disk copy routine to simultaneously create and optionally verify up to 
seven copies of a single 8430 or 8433 disk, regardless of the disk’s contents. The 
verification process ensures that your disk was copied correctly by comparing the contents 
of the input with that of your output. You can also use this routine in a separate operation 
to verify copies that were made by a previous SU$CSL disk copy operation or a disk copy 
operation using the dump/restore routine. 


You can execute SU$CSL either interactively from a workstation or in a batch 
environment. Both methods achieve the same results. 


15.3.1. Executing SUSCSL in an Interactive Environment 


Interactive processing of the SU$CSL routine consists of a question and answer session 
(dialog). Before executing SU$CSL, you must have successfully logged on to the system via 
the LOGON command. After logging on, key in HU in system mode and press XMIT. After 
pressing XMIT, the following menu screen appears: 


HARDWARE UTILITIES 


- DUMP FILES FROM A DISK 

« RESTORE FILES TO A DISK 

- LIST FILES ON A BACKUP MEDIUM 

« COPY FILES FROM DISK TO DISK 

- COPY AND/OR VERIFY 8419 DISK 

» COPY AND/OR VERIFY 8416/8418 DISK 
« COPY AND/OR VERIFY 8430/8433 DISK 
.« NONE OF THESE 


1 
2 
3 
4 
5 
6 
7 
8 


ENTER SELECTION 
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Select 7 from the menu screen to start execution of the SU$CSL routine. After you press 
XMIT, the following HU00CI06 informational screen appears: 


HU@OC1 G6 


A CONVERSATIONAL JOB (HUSCSL) TO COPY THE CONTENTS OF ONE 
8430/8433 DISK TO ONE OR MORE DISKS OR TO VERIFY THE CONTENTS OF 
ONE OR MORE DISKS HAS BEEN INITIATED IN YOUR BEHALF. 


YOU MUST BE IN SYSTEM MODE FOR THE JOB TO BE SCHEDULED. IF YOU 
ENTERED HARDWARE UTILITIES THROUGH THE HU COMMAND YOU WILL BE IN 
SYSTEM MODE AFTER TRANSMITTING. IF YOU ENTERED THROUGH THE MENU 
COMMAND YOU ARE RESPONSIBLE FOR GOING INTO SYSTEM MODE. 


eeeee TRANSMIT TO CONTINUE ***** 





After reading the message screen indicating that a copy job was initiated, press XMIT. 
_ Screen 1 is displayed. 


Screen 1 (HU10): Indicating Disk Device Type and Volume Serial Number 


COPY INPUT DEVICE INFORMATION 





ENTER SPECIFIC DISK DEVICE TYPE: 
ENTER VOLUME SERIAL NUMBER: 


weaweeee FUNCTION KEYS: F13=HELP, FI4=EXIT HELP ******4* 





Looking at Screen 1, we entered 8433 for the disk device type and ABC123 for the volume 
serial number. The device type entered on this screen can be an 8430 or 8433 disk pack. 
Since help is not required, press XMIT and the following screen appears: 


Screen 2 (HU13): Indicating Number of Copies, Start/End Addresses, and Verification Option 


COPY -VERIFY HU13 


COPIES - UP TO 7 copy=4 


BEGIN ADDRESS (CCC) BGAD=000 


END ADDRESS (CCC) EDAD=327, 


ONLY VERIFY OVEF=NO 


wwaweeee FUNCTION KEYS: FI3=HELP, FI4=EXIT HELP 9 *****eee 
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Looking at Screen 2, we entered 3 for the number of copies (overriding the default of 1), 
took the default for the beginning and ending addresses (cylinder 000 for beginning and 
327 for ending), and took the default option NO, indicating that we are doing a “copy” 
operation and not a “verify-only” operation. Since help is not required, press XMIT. 


Screen 3 (HU14): Indicating the File Options 


HU14 


UNEXPIRED FILE CHECKING UNXF=YES 


VERIFY very={fag 


weewnees FUNCTION KEYS: FI3=HELP, FIG=EXIT HELP *****8e8 





On this screen, we want unexpired file checking and output verification. We entered YES 
for output verification and allowed the unexpired file checking option (UNXF) to default to 
YES. Unexpired file checking checks the output volume for file expiration dates. If the date 
has not expired and you are in system mode, the workstation screen displays a message. 
This message asks you either to terminate or to skip the file and continue processing. You 
can skip up to 10 files at a time. (The expiration option must not be used with unprepped 
output disk packs. To do so results in a space management error.) Verification ensures that 

@ an exact copy of your input is produced. Any errors detected are printed by using the print 
option (next screen). 


Screen 4 (HU15): Indicating the Print Option 


COPY -VERIFY 


PRINT ALL ERRORS PRNT=YES 





Since we specified the verify option on the last screen, we recommend that you take default 
YES to print any errors detected during the copy process. Press XMIT. 
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Screen 5 (HU11): Specifying Output Device Information 


COPY OUTPUT DEVICE INFORMATION 


ENTER SPECIFIC DISK DEVICE TYPE: 


ENTER VOLUME SERIAL NUMBER(S): 


weekeeRR FUNCTION KEYS: FI3=HELP, FI4=EXIT HELP ****#*88# 





On this screen, we entered 8433 as our output disk device type. Next, we entered volume 
serial numbers DISK04, DISK05, and DISKO6 for the three copies of our output. The 
number of underscored input fields requesting volume serial numbers that appear on the 
screen are equal to the number of copies specified on Screen 2. Press XMIT to complete the 
copy operation. After you press XMIT, the workstation becomes free for other uses and the 
following informational message screen (HU25) appears. When the job is finished, your 
workstation screen displays an end-of-job message. 














HARDWARE UTILITIES HU25 
THE INTERACTIVE INTERFACE FOR THIS PROGRAM 
HAS NOW BEEN COMPLETED. THIS WORKSTATION WILL BE 
AVAILABLE FOR USE WHILE THE PROGRAM PROCESSES AS 
YOU REQUESTED. 





15.3.2. Executing SUSCSL in a Batch Environment 


When executing SU$CSL in a batch environment, you must supply the appropriate job 
control statements defining your devices. All the options available to you in an interactive 
environment are supported in batch. 


SUSCSL Organization 


SU$CSL has seven parameters that control its operation. All these parameters have 
default values and are associated with the // PARAM statement as was the case with 
SU$C16. However, if you choose all the defaults, you must still have the // PARAM 
statement present in your control stream. SU$CSL checks the file control block to 
determine the type of disk pack being copied. 
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The format of SU$CSL is 


alae i aaa lt 


’ BGAD= { ccchh 16 ,EDAD= 








Use the COPY parameter to indicate how many copies of your input disk pack are to be 
made. The value of n may be from 1 to 7. If you omit COPY, one copy is made. 





Use the VEFY parameter to verify your new output. If you are making more than one copy, 
each copy is verified against the input. If you omit VEFY, no verification is performed. 


Use the PRNT parameter to print any records found to be in error. If an error is detected, 
both the input and output record is listed with its corresponding output disk address 
(cechhrr), in hexadecimal. You would normally choose PRNT=YES if you had chosen 
VEFY=YES. If you omit PRNT, only fatal errors are written on the system console. 


Use the OVEF parameter to indicate that a verify-only operation is to be performed. No 
copy will be made. If you omit OVEF, one or more copies will be made, with or without 
verification, depending on other parameter specifications. OVEF may be used in 
conjunction with BGAD and EDAD. 


Use the BGAD parameter to indicate the starting address of the first track to be copied, in 
hexadecimal. The address you specify must be the cylinder and head number (ccchh). If you 
omit BGAD, the beginning address is cylinder 000, head 00. 


Use the EDAD parameter to indicate the ending address of the last track to be copied in 
hexadecimal. As explained in the BGAD parameter, the address you specify must be the 
cylinder and head number (ccchh). If you omit EDAD, the values will be defaulted for each 
device as shown in the format. 


Since the programming logic of SU$CSL is similar to that of SU$C16, the input addresses 
are the same as your output addresses and any information contained in your specified 
output area is destroyed and the new information is written in that area. 


Use the UNXF parameter to check for the file expiration date. If the file date has not 
expired, a message is displayed that asks you either to continue processing or to skip the 
file and continue to the next file (providing you are processing more than one file). Using 
the UNXF parameter eliminates the time and expense of keeping outdated files. It also 
eliminates the overlaying of files that should not be destroyed. 
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SUSCSL Interfacing with Job Control 


The file name DISCIN must be specified on the // LFD job control statement for your input 
disk pack. The file name DISCOT must be specified on the // LFD job control statement for 
your output disk pack. If you are copying onto more than one disk pack, then DISCOTO1 
through DISCOTO6 must be specified for each additional disk pack being copied. 


Executing SUSCSL 


In a multijob environment, the use of SU$CSL can cause space allocated to a file to be lost, 
files may be added to or portions deleted, or a disk pack may be incorrectly copied. These 
situations can occur when another job is updating the VTOC of a disk pack at the same 
time SU$CSL is copying that VTOC to another disk pack, or when SU$CSL is copying a 
file while another job is extending or scratching that file. Therefore, the job executing 
SU$CSL must be the only job running when the I/O device is either SYSRUN or SYSRES. 
If the device is not SYSRUN or SYSRES, it must be set to nonshareable by the operator. 
This ensures that an exact copy will be made by SU$CSL. 


Programming Examples 


The following control streams show some typical examples of how to use SU$CSL: 


Example 1 @ 








// JOB COPY8433 

// DVC 50 // VOL DSP@@1 // LFO DISCIN 
// DVC 51 // VOL DSPO@2 // LFD DISCOT 
// EXEC SUSCSL 


Here is a basic 8433 disk copy. There is no printing or verification. Your starting 
address is cylinder 000, head 00, while your ending address is cylinder 327, head 12. 


Example 2 





// JOB COPY8433 

// OVC 50 // VOL DSPO@1 // LFD DISCIN 
// DVC 51 // VOL DSP8@2 // LFD DISCOT 
// DVC 28 // LFD PRNTR 

// EXEC SUSCSL 

// PARAM PRNT=YES, VEFY=YES, EDAD=050 
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Here, you are only copying up to cylinder X‘50’, as indicated by EDAD=050. You are 
also using the verification and print options, making sure the information written is 
the same as that read. 


Example 3 
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// JOB COPY843@ 

// DVC 58 // VOL DSP@O1 // LFD DISCIN 

// DVC 51 // VOL DSP@82 // LFD DISCOT 

// DVC 52 // VOL DSP@83 // LFD DISCOTO1 

// DVC 20 // LFD PRNTR 

// EXEC SUSCSL 

// PARAM COPY=2, VEFY=YES, PRNT=YES, BGAD=010, EDAD=18@, UNXF=YES 
/& 

// FIN 


Here, you are using all the parameters. You are making two copies by using the 8430 
disk packs. Your copy starts at cylinder X‘10’ and ends at cylinder X‘100’ with 
verification and printing of any errors being detected, as well as file expiration date 
checking. 
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Section 16 


System Utility Symbiont 


The system utility symbiont (SL$$SU) is a multipurpose utility that allows you to 
perform various functions using cards, tapes, disks, or diskettes. Table 16-1 breaks 
down the different functions to the media associated with them. 


Table 16-1. SLSSSU Functions 
Function Code | Function Performed 
Card Functions 

cc Reproduces cards punched in Hollerith code. 

CCB Reproduces cards punched in binary and Hollerith code. 

ccs Reproduces and resequencing source programs. 
& cT Writes card to tape in unblocked format. 

CTR Writes card to tape in blocked format. 

cP Lists cards. 

CH Lists cards containing compressed mode. 

JCP Punches cards from the system console. 

TT Copys a tape to another tape. 

TH Prints a tape in character and hexadecimal format. 

THR Prints a tape in character, hexadecimal, deblocked format. 

TP Prints a tape containing only standard characters. 

TPR Prints a tape in character and deblocked format. 

TRS Locates a specific record on tape. 

Tc Punches cards from tape. 





continued 
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Table 16-1. SLSSSU Functions (cont.) 


Function Code | Function Performed 


Card Functions (cont.) 






















Preps a tape. 


FSF Forward spaces to a specific file. 

BSF Backward spaces to a specific file. 
FSR Forward spaces to a specific record. 
BSR Backward spaces to a specific record. 
WIM Writes tape marks. 

REW Rewinds a tape. 

RUN Rewinds a tape with interlock. 


Erases a portion of a tape. 


Disk/Format Label Diskette Functions 


Displays available disk extents on the console screen 


DD Prints a disk in unblocked format. 
DDR Prints a disk in reblocked format. 
SVT Prints a short-format VTOC file. 


Prints the volume table of contents of a disk. 


Diskette Functions 


Prints a diskette in unblocked format. 





Prints the data set labels of a diskette. 
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Section 17 
Buffer Analysis Routine 


The buffer analysis routine prints information about dynamic buffers, using the 
$Y$DUMP file as input. 


Format 


RU BUFLIST, ,V=vsn,BUF= (i 


om rn 


where: 


V=vsn 
Specifies the volume serial number of the resident device. The volume serial 
number of the $Y$DUMF file is the default. 


BUF = 
Specifies the type of buffer analysis report to be printed. 


BUF=B 
Specifies the brief option, which prints totals only. This is the default. 


BUF=S 
Specifies the short option, which prints information only for those lists 
that contain buffers. 


BUF=L 
Specifies the long option, which prints information about every buffer 
on a list as well as the total bytes used by allocated and free buffers. 


BUF=E 
Specifies the extended option, which is the same as the long (L) option, 
but also includes information about memory usage, starting with the 
first buffer area and scenning to the end of memory. 


BUF=D 
Specifies the debug option, which is the same as the long (L) option, but 
also prints selected data bases in hexadecimal format. This option is 
useful for debugging the program. 
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Appendix A 


Canned Job Control Streams 


A.1. Referencing the Canned Job Control Streams 


The following canned job control streams provide you with a more convenient method 
of performing some system utilities without the need of punching the parameters and 
job control statements normally required to run them. The utilities reside in the 
system load library file ($Y$LOD), and their corresponding job control streams reside 
in the system job control stream library file ($Y$JCS). The utilities are initiated from 
the system console by keying in their associated job control stream name. 


Table A-1 shows the job names associated with the utilities, the functions performed, 
and the manuals where they can be found. 


a Job Name 


CGV/CHGVSN 
ocoP 

ORDP 
DUMPLOG 
DUMPLOGT 


JBLOG 


UP-8841 Rev. 4 


Table A-1. Canned Job Control Streams 


Changes a volume serial number on a 


previously prepped disk. 


Copies SYSRES to another disk of 
the same type. 


Prints directory partition of a 
Librarian disk file. 


Dumps job or console log records 
to disk. 


Dumps job or console log records 
to tape. 


Produces a job accounting report 
with SYSLOG residing on disk. 





Described in Document 


System Service Programs (SSP) 
Operating Guide (UP-8841) 


Installation Guide (UP-8839) 
System Service Programs (SSP) 
Operating Guide (UP-8841) 


Spooling and Job Accounting 
Concepts and Facilities (UP-8869) 


Spooling and Job Accounting 
Concepts and Facilities (UP-8869) 


Spooling and Job Accounting 
Concepts and Facilities (UP-8869) 


continued 
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Job Name 


COPYREL 


IMPLDSKT 


JBLOGT 


LISTRES 


MODLST 


SCLIST 


SETREL 


SMCLIST 


SYSDUMP 


SYSDUMPO 


Table A-1. Canned Job Control Streams (cont.) 


Copies SYSRES files to a new SYSRES 


volume. 





Creates an IMPL diskette. 


Produces a job accounting report 
with SYSLOG residing on tape. 


Prints directory for SYSRES modules. 


Lists the contents of the system 
libraries. 


Lists the shared code ($Y$SCLOD) 
modules. 


Preps and allocates RELEASE/SYSRES 
files. 


Lists software maintenance 
corrections. 


Prints a complete system dump from 
SYSRES or another system disk. 


Prints a complete system dump or a 
portion of a system dump from 
SYSRES or another system disk. 





Installation Guide (UP-8839) 


Installation Guide (UP-8839) 


Spooling and Job Accounting 
Concepts and Facilities (UP-8869) 


system Service Programs (SSP) 
Operating Guide (UP-8841) 


System Service Programs (SSP) 
Operating Guide (UP-8841) 


Supervisor Technical Overview 
(UP -8831) 


Installation Guide (UP-8839) 
System Service Programs (SSP) 
Operating Guide (UP-8841) 


Dump Analysis User Guide/Programmer 
Reference (UP-8837) 


Dump Analysis User Guide/Programmer 
Reference (UP-8837) 
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A.2. Copying Release or SYSRES Libraries 
(COPYREL and SETREL) 


For convenience, we show the formats of the COPYREL and SETREL canned job 
control streams. You use SETREL first to prep your disk and assign the system files 
that will reside on the disk after you execute COPYREL. Not only are COPYREL and 
SETREL useful during your system installation, they can be used any time you need 
to copy all the RELEASE or SYSRES volume libraries to a backup disk of any type. 


The format of COPYREL is 


RVACOPYREL, , V=vsn, T= { 16 \ ,[,S=first-file](,L=last-file][,CAT=Y][,SEC=Y] 
17 
18 
19 
30 
33 
78 
94 


The form=: of SETREL is 


RVASETREL, , V=vsn, T= {16 \ ,P=prep- type ,CR=NOI[,R=n] 
7 
© : 
19 
30 
33 


70 
94 


For a complete description of COPYREL and SETREL, see the current version of the 
Installation Guide (UP-8839). 
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Appendix B | 
Code Set Components 


B.1. Introduction 


A code set defines the types of records needed to make up a particular type of module 
or a module group. It also defines the required sequence for these records. The 
recognized code sets are summarized below and are described in detail in B.2. 


A. 


UP-8841 Rev. 4 


Grouped Code Sets 


1 beginning-of-group demarcator, type AO 

1 or more source, macro/jproc, object, or load module code sets 
1 end-of-group demarcator, type A8 

1 EOF code sentinel, type Al 


Program Source and Macro/Jproc Source Module Code Sets 


1 header, type A3 or A4 
1 or more source items, type 24 or 25 


Object Code Sets 


1 header, type 80 

1 or more linkage editor control statements, type 40 (optional) 
1 or more CSECT, types 08, 09, 0A, OB 

1 or more ESD, types 04, 06, 07 (optional) 

1 or more text, type 02 

1 transfer, type 03 

1 or more linkage editor control statements, type 40 (optional) 
1 or more ISD records, type 0C 


Load Code Sets 


1 header, type 90 or BO (root phase definition) 

1 or more SENTRY, type C4 (optional) 

1 or more sets of resource and SEXTERN records, type C8 and C6 (optional) 
1. or more text, type 12 or 32 

1 transfer, type 13 

1 or more sets phase definition (type 90 or BO), text (type 12 or 32), and 
transfer (type 13) records, depending on the number of phases in the load 
module (optional) 

1 or more ISD records, type 1C 
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B.2. Description 


B.2.1. Grouped Code Sets 


Modules in a file can be grouped by inserting beginning-of-group and end-of-group 
demarcator records within the file. A single group can contain modules of assorted 
types. The use of groups is optional and determined by the user. 


The librarian is used to insert the beginning-of-group and end-of-group records in the 
file. Once the groups are created, the librarian can also be used to manipulate the 
module code sets on a group-by-group basis. 


Groups may be nested to any number of levels. (Figure B-1 illustrates nested groups.) 
The formats for a beginning-of-group, end-of-group, and end-of-file sentinel records 
are given in Tables B-1 through B-3. 





NESTED Ser 
GROUP A4 westep J GROUP SET 


GROUP 4 © SET 


DG) 2 SOO Be oe Nam 


ete te 


Figure B-1. Example of Nested Group Code Sets 
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Table B-1. Beginning-of-Group (BOG) Header Record Format 












Byte 
Position 









Length prefix 38 (binary format) 


Type prefix AG46 

Symbolic name of logical group of code sets 
contained within the group starting with this 
record (left- justified and space- filled) 


Group name 


Up to 3@ bytes of comments to identity the group 





Table B-2. End-of-Group (EOQG) Trailer Record Format 







Byte 
Position 












Contents 


@ Length prefix 8 (binary format) 
1 Type prefix ABag 
2-9 Group name Symbolic name of logical group of code sets 


contained within the group starting with this 
record (left- justified and space- filled) 





Table B-3. End-of-File (EOF) Sentinel Record Format 











Byte 
Position 





Contents 













Length prefix 20 (binary format) 


Type prefix A@ag 


2-13 Unused 0846 


Name ENOLIBAA 
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B.2.2. Source Module Code Sets 


A source module code set is composed of source module code statements. These may be 
macro definitions, own-code specifications, jprocs written in job control language, or 
source statements for a specific language processor. The formats for source module 
header and source statement records are given in Tables B-4 through B-6. 


Table B-4. Source Module Code Header Record Format 





Byte 
Position Contents 
@ Length prefix 56 (binary format) 
1 Type prefix A344 OF Abag 
2, 3 Unused 00,46 
4 Flag Bit @ (88,,) Set to indicate module has 
been corrected. 
Bit 1 (484,) Reserved 
Bit 2 (2046) Set to indicate that module 
is deleted. 
5-13 Unused 084, 
14-21 Module name Symbolic name of the source code set started by 
record (left- justified and space- filled) 
22-24 In the form as it appears in the preamble 
25-26 Hour-minute (packed decimal tess zone field) 
27 084, 
28-57 Up to 3@ bytes of comments to identify the 


source module 
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Table B-5. Source Module Code Statement Record Format 













. Byte 
Position 





Contents 







Length prefix Variable: 2 + length 


Type prefix 2446 





Source record Source statement 


Table B-6. Compressed Source Module Code Statement Record Format 















Byte 
Position 





Contents 





Variable: 2 + compressed source length 





Length prefix 
Type prefix 35 16 


Source record Compressed source statement 


B.2.3. Object Code Sets 


An object module code set consists of text and relocation data output by a particular 
language processor. It can also contain control statement records used by the linkage 
editor to generate load code. Object module records are variable-length records and 
are packed as densely as possible within a given library block. The desired record 
sequence is: 

¢ Object module header record 

¢ Control statement records* 

¢ All control section records (must precede associated text and entry ESDs) 

e All ESD records (Names must be unique.) 

e  AllLISD records** 


* Control statement records are generated by certain language processors and may be used to designate control information 
necessary to a subsequent linkage editor run. 


** ISD records are also generated by certain language processors and are used by JOBDUMP to produce a formatted dump if an 
abnormal termination occurs in your load module. 
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¢ All text/RLD records 

¢ Object module transfer record 

* Control statement records 

These records are described in Tables B-7 through B-16. 


Table B-7. Object Code Header Record Format 





Byte 
Position Contents 
@ Length prefix 55 (binary format) 
1 Type prefix 8016 
2 ESID 8046 
3 Unused Bit 0 (8844) Set to indicate that the 
module has been patched. 
Bit 1 (4846) Reserved 
Bit 2 (2046) Set to indicate that module 
has been deleted. 
Bit 3-6 Not used 
Bit 7 (8146) Set to indicate that the 
module is reentrant. 
5-8 Address Assembled or compiled origin of object module 
9-12 Module length Total number of bytes required for object module. 
13-20 Module name Symbolic name of object module started by this 
record (left- justified and space-filled). 
21-23 In the same form used in the preamble 
24, 25 Hour-minute (packed decimal less zone field) 
26 


884, 


Up to 38 bytes of comments to identify object module 
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Table B-8. Object Code Control Section Record Format 


Byte 
Position Contents 
@ Length prefix 19 (binary format) 
1 Type prefix 0846, 0946, OA,6, OF OBy, (see Table B- 10) 
2 ESID External symbol identification assigned to this 
control or common section. 
3,4 Flag bytes 80001, indicates a deferred length specified in 


the transfer record of this object module; 
ignore bytes 9 through 12. 


5-8 Section address | Compiled address of the start of this control 
or common section 


9-12 Section size Total length in bytes of this control or common 
section 
13-28 | Section name Symbolic name of the control or common section 


(left- justified and space- filled) 





Table B-9. Possible Control Section Record Types 


Record |Record 
Type Length 
68 























Field Contents 


SE Ese 


0900,, Address| Length 
or 80001, 


Type 
of 
Control Section 


Control 
section name 


Name control section 





Blanks (4846) 






Common 
section name 






Blanks (40,,) 
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Table B-10. Object Code ESD Record Format 






















Byte 


Position 


15 (binary format) 





Length prefix 


Type prefix 0446, 064,, or W746 (see Table B- 12) 


2 ESID External symbol identification assigned to this ESD 
reference 

3,4 Unused 001, 

5-8 Relative Address Processor-generated address or value assigned to 


this ESD reference 


Symbolic name of the ESD reference 





Table B-11. Possible ESD Record Types 





Field Contents 
Record Record 
me foes Fe [ae [me 


} esto | 0008,, Assembled address 
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Table B-12. Object Code ISD Record Format 


. Byte 
Position Contents 

8 Length prefix Variable 

1 Type prefix OC. 

2 ESID External symbol identification of CSECT 
assigned to the ISD 

3 Flag Bits @ and 1 unused 
Bit 2 set to indicate Type 3 ISD 
Bit 3 set to indicate Type 4 ISD (comment) 
Bit 4 through 7 unused 

4 Flag Unused 

5-8 Compile origin Processor-generated address assigned to this ISD 

9-246 Attributes Symbolic name and attributes of the ISD item 





Table B-13. Object Code Text/RLD Record Format 


Byte 
Position Contents 
@ Length prefix Variable: 7 + text length + RLD length (binary format) 
1 Type prefix Q216 
2 ESID External symbol identification with which text data 
in this record is associated 
3 Text length Number of bytes less 1 of text data in this record 
4 RLD length Number of bytes of relocation data in this record 
(multiple of 3 bytes) 
5 Flag ®146 if patched text item 
6-8 Relative address| Processor-assigned relative address of first byte of text 


data in this record 





continued 
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Table B-13. Object Code Text/RLD Record Format (cont.) 
















Byte 
Position 








9 through 9 + 
text length 


Text data Instructions and/or data generated by a processor and 


relative to the ESID specified 


9 + text length 
+ RLD length 
backward thru 
9 + text length 


RLD data Three-byte relocation masks used to modify the various 


preceding text data in this record (see Table B-14) 


Table B-14, Relocation Mask Format 















Byte 
Position 





External symbol identification of the external reference whose 
subsequent value will be used to modify the addressed field 





Designator byte reflecting type, size, and position of the 
modification field (see Figure B-2) 


Relative record pointer indicating the most significant 
(leftmost) byte of text data at which the modification is to 
begin (first text byte, 0; 2nd byte, 1, etc.) 


Notes: 


1. Each RLD data field in a given text record is composed of 3 bytes of relocation information designating the field 
size, field position, and associated external index relevant to the modification of the addressed data bytes in this 
text record. The field may be positively or negatively relocated at link-edit time and can be modified by one or 
more relocation masks. The text and its associated relocation masks always must appear within the same 
logical record. 


2. Load module relocation masks are identical, except that the ESID field represents the phase number assigned to 
the definition referenced by the address constant in the linked load module. 
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Figure B-2 is a sample relocation mask field. 





RLD FIELD 






Address (in hexadecimal) pointing to the leftmost byte on the field to be 
modified. The position is relative to the first byte of text in the record 
{0 refers to the 1st byte, 1 to 2nd, etc.) 


This 5-bit field indicates the number of bits to be 
modified. This number is one less than the actual 
number of bits used (0-31). The 7-, 15-, 23-, and 
31-bit modifications may apply only to load 
module RLD. 


3 0 - Rightmost bit of the modification field is on 
a byte boundary. (Always 0 for load module RLDs). 


1 - Rightmost bit of the modification field is on 
a half-byte (hexadecimal) boundary. 


2 1 - V-type address constants 
0 - Others (always 0 for load module RLDs) 


Type of relocation 
0 - Addition (+) 
1 - Subtraction (-) 


The ESID referring to the ESD entry in the module on whose value the relocatable data depends. 


If a load module RLD, this byte reflects the phase number of the phase supplying the definition 
for this reference. 





Figure B-2. Relocation Mask Field 
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Table B-15. Object Code Transfer Record Format 


Byte 
Position Contents 
i] Length prefix 11 + RLD (binary format) 
1 Type prefix 8346 
2 ESID External symbol identification assigned to the. 
transfer reference 
3: Text length 3 (binary format) 
4 RLD length Number of bytes of relocation data in this 
record (multiple of 3 bytes) 
5 Flag 8016 if deferred length is present in bytes 6-8. 
4046 if transfer record does not terminate 
object module (1 or more control 
statements follow). 
6-8 Deferred length | One CSECT or common section (named, unnamed, or 


blank) may have its respective record flagged to 
indicate that the object module transfer record 
specifies the actual length. 


9-12 Transfer address} Processor-generated object module transfer 
address 


13-13 + | RLD data Relocation data to modify transfer address 
RLD length 





Table B-16. Object Code Control Statement Record Format 













Byte 
Position 





Contents 





Length prefix 88 (binary format) 





Type prefix 4046 






Control statement} Source control statement 


Note: Any control statements appearing in an object module must directly follow a header record or a transfer 
record. The latter case is indicated by the appropriate setting of the flag byte in the transfer record. 


B-12 UP-8841 Rev. 4 











Code Set Components 


®@ B.2.4. Load Code Sets 


A load module code set is produced by the linkage editor and is loaded into the system 
by the system load facility at the time of program execution. A load program may be 
composed of one or more phases, or program segments. The sequence of records in 
each phase of a load module is 


Phase definition record 

One or more SENTRY records (optional) 
One or more resource records (optional) 
One or more SEXTRN records (optional) 
One or more ISD records (optional) 

One or more text/RLD records 


Transfer record 


Every load program contains an initial phase called the root phase. (Automatically 

included modules also become resident in the root phase.) Each phase segment 

contains its own transfer record, which identifies the end of the phase and possibly the 

starting address for program execution. The formats for load module code set records 
@ are given in Tables B-17 through B-21. 


Table B-17. Load Code Phase Definition Record Format 


Byte 
Position Contents 
@ Length prefix 67 (binary format) 
1 Type prefix ag 
2 Phase number Linkage-editor-assigned phase number of this phase 
3,4 Flag Byte 3 
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Bit 8 (80,4) Set in root phase header to 
indicate clear module 
partition as defined in 
bytes 27 through 38. 


Bit 1 (40,.) Set to indicate that the 
load module calls reentrant 
code. 





continued 
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Table B-17. Load Code Phase Definition Record Format (cont.) 


Byte 
Position 
5-8 Phase load address 
9-12 Phase length 


13-20 Phase name 


21-23 Date 


24, 25 Time 


26 SENTRY count 


B-14 





Contents 


Bit 2 (204) 


Bit 3 (1844) 


Bit 4 (084) 


Bit @ (8046) 


Bit 1 (4046) 


Bit 2 (2044) 


Bit 3-7 


Set to identify the load 
module as reentrant. 


Set to identify the load 
module as base ®@ shared 
code. 


Set to identify the load 
module as key @ shared code. 


Reserved 


Set to indicate that module 
has been patched. 


Reserved 


Set to indicate module has 
been deleted. 


Not used 


Linkage-editor-assigned relative origin of this 


phase 


Total number of bytes required for this phase 
segment; value represents the highest zero relative 
address assigned to this phase. 


Symbolic name assigned to this loadable phase 


segment 


Month-day-year (packed decimal less zone field) 


Hour-minute (packed decimal less zone field) 


Number of SENTRY records contained in the load 


module 


continued 
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Table B-17. Load Code Phase Definition Record Format (cont.) 











Byte 
Position 














Module length Total number of bytes required for loading the 
module; value represents the highest zero relative 


address assigned to the load module. 





31-38 Al jas-phasename Symbolic name assigned to this loadable phase 
segment by the Linkage editor OVERLAY or REGION 
control statement that created the phase 

39-68 Up to 3@ bytes of pertinent comments as deemed 


necessary to identify the load module segment 


Table B-18. Load Module Shared Code Record Format 









Contents 





Byte 
Position 


Resource SEXTRN SENTRY 
Records Records Records 
















Length prefix 15 (binary format) 15 (binary format) 15 (binary format 


































1 Type prefix C84, C61, Chay 

2 Number Resource number SINDEX number SENTRY number 

3, 4 Unused 

5-8 Length Resource size Byte 5 has resource Link address 
number 
Bytes 6-8 unused 

9-16 Resource name (left-| SEXTRN name (left- SENTRY name (left- 






justified and zero- 
filled) 


justified and blank- 
filled) 


justified and bl ank- 
filled) 
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Table B-19. Load Code ISD Record Format 


Byte 
Position Contents 
@ Length prefix Variable 
1 Type prefix 1c 
2 Phase number Linkage-editor-assigned phase number of this phase 
3 Flag Bit @ set to indicate Type 1 ISD (CSECT) 
i Bit 1 set to indicate Type 2 ISD (comment) 
Bit 2 set to indicate Type 3 ISD 
Bit 3 set to indicate Type 4 ISD (comment) 
Bits 4-7 unused 
4 Flag Unused 
5-8 Link origin Linkage-editor-assigned relative origin for this 
IsD record : 
9-12 Compile origin Language-processor-generated address to the ISD 
record 
13-16 Size Size of this ISD record 
17-258 | Attributes Symbolic name and attributes of this ISD record 





Table B-20. Load Code Text/RLD Record Format 






Byte Contents 


Position 












Length prefix 






Type prefix 1246 








Linkage-editor-assigned phase number of text data in 
this data 


Phase number 


Text length Number of bytes less 1 of text data in this record 





continued 
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Variable: 7 + text length + RLD length (binary format) 
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Table B-20. Load Code Text/RLD Record Format (cont.) 


Byte 
Position 


9 through 9 + 
text length 


9 + text length 
+ RLD Length 


backward thru 
9 + text length 


_ Byte 
Position 


9-12 


13 through 13 + 
RLD 
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RLD length 


Flag 


Load address 


Text data 


RLD data 


Contents 
Number of bytes of relocation data in this record 
(multiple of 3 bytes) 
O14, if a patched text item 


Linkage-editor-assigned phase segment load address 
assigned to the first byte of text data in this record 


Instructions or data to be loaded relative to the load 
address 


Three-byte relocation masks used to modify text in the 
record (see Table B-14) 


Table B-21. Load Code Transfer Record Format 


Length prefix 
Type prefix 
Phase number 


Text length 


RLD length 


Unused 


Transfer address 


RLD data 





Contents 


11+ RLD data length (binary format) 

1346 

Linkage-editor-assigned phase number of this phase 
3 (binary format) 


Number of bytes of relocation data in this record 
(multiple of 3 bytes) 


0016 
Linkage-editor-assigned phase segment transfer address 


Relocation data used to modify the transfer address 
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B.2.5. Block Load Code Sets e 


Unlike standard load modules which use two file partitions, block load modules use 
three partitions. Partition 1 contains directory records just like those for standard load 
modules. Partition 3 contains the actual block module text records in sequential load 
order. These text records contain unstructured, contiguous text data, free of any 
control information. This data is binary zero-filled. The data records in partition 2 
define the boundaries of each phase in partition 3. 


Tables B-22 through B-27 describe the formats for the records within a lock load code 
set in sequential order as they occur in the file. 


Table B-22. Partition 1 - Directory Entry 










Byte 
Position 







Symbolic name 








Type flag (B8,,) 


9-11 Block relative pointer 





Record relative pointer 








Table B-23. Partition 2 - Block Load Module Header Record 












Byte 
Position 





Contents 









Length prefix 75 (binary format) 









Type prefix B46 








2 Phase number Linkage-editor-assigned phase number of this phase 
3,4 Flag Byte 3 
Bit @ (8846) Set in root phase header to 


indicate clear module 
partition as defined in 
bytes 27 through 3@. 





continued 
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Table B-23. Partition 2 - Block Load Module Header Record (cont.) 


Byte 
Position Contents 
Bit 1 (4044) Set to indicate that load 
module calls reentrant code. 
Bit 2 (2044) Set to identify load 
module as reentrant. 
Bit 3 (1844) Set to identify load module 
module as base ® shared code. 
Bit 4 (08,6) Set to identify load module 
as key ®@ shared code. 
Bit 5-7 Reserved 
Byte 4 
Bit @ (8046) Set to indicate that module 
has been patched. 
Bit 1 (4846) Reserved 
Bit 2 (2846) Set to indicate module has 
been deleted. 
Bit 3-7 Not used 
5-8 Phase load address Linkage-editor-assigned relative origin of this 
phase 
9-12 Phase length Total number of bytes required for this phase 
segment; value represents highest relative zero 
address assigned to this phase. 
13-28 Phase name Symbolic name assigned to this loadable phase 
segment 
21-23 Date In the form as it appears in the preamble 
24, 25 Time Hour-minute (packed decimal less zone field) 
26 SENTRYs count Number of SENTRYs recorded 





continued 
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B-20 


Table B-23. Partition 2 - Block Load Module Header Record (cont.) 


Byte 

Position Contents 

27-30 Module Length Total number of bytes required for loading the 
module; value represents highest relative zero 
address assigned to the load module 

31-38 Al ias-phasename Symbolic name assigned to this loadable phase 
segment by the Linkage editor OVERLAY or REGION 
control statement that created the phase 

39-68 Up to 3@ bytes of pertinent comments as deemed 
necessary to identify the load module segment 

69-71 Pointer to text block (beginning of this phase in 
partition 3) 

72-74 Block number Pointer to first text or transfer block of this 
phase in partition 2 

75 Displacement Pointer to first text or transfer record of this 
phase in partition 2 

76 Checksum XOR of first byte of each text block of partition 3 





Table B-24. Partition 2 - Block Load Module RLD Record 










Byte 


Position Contents 














1 + number of RLD times 5 (binary format) 





Length prefix 
Type prefix 3246 


Length of RLDs Number of RLD masks times 5 





3(3 + n x 5-1) RLD masks Five-byte RLD masks (see Table B-25) 





UP-8841 Rev. 4 

















Code Set Components 





Table B-25. RLD Mask 












Byte 
Position 






Contents 


Phase number (in load module RLD mask) 


Load module relative address 


Bits Cin load module RLD masks) 


Table B-26. Partition 2 - Block Load Module Nonphase Text/RLD Record 


. Byte 
Position 
@ Length prefix 
1 Type prefix 
2 Phase number 
3 Text length 
4 RLD length 
5 Flag 
6-8 Load address 
9 through 9 + Text data 


text length 


9 + text length RLD data 
+ RLD length 
backward thru 
9 + text Length 





Contents 


Variable: 7 + text length + RLD length (binary format) 


lag 


Linkage-editor-assigned phase number of text data in 
this record 


Number of bytes less 1 of text data in this record 


Number of bytes of relocation data in this record 
(multiple of 3 bytes) 


8146 if a patched text item 


Linkage-editor-assigned phase segment load address 
assigned to the first byte of text data in this record 


Instructions and/or data to be loaded relative to the 
load address 


Three-byte relocation masks used to modify text in the 
record (see Table B-14) 


Note: Nonphase text records are present in block load modules when text/RLD items are detected that are not part 
of a given phase. Such text/RLD items outside the phase being loaded are to be loaded at the same time. 
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Table B-27. Partition 2 - Block Load Module Transfer Record 


Byte Contents 

Position 

@ Length prefix 11 + RLD data length (binary format) 

1 Type prefix 346 

2 Phase number Linkage-editor-assigned phase number of text phase 

3 Text Length 3 (binary format) 

4 RLD length Number of bytes of relocation data in this record 
(multiple of 3 bytes) 

5-8 Unused 884. 

9-12 Transfer address| Linkage-editor-assigned phase segment transfer address 

13 through 13 + | RLD data Relocation data used to modify the transfer address 

RLD length 
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Appendix C 
SAT Library Structure 


C.1. Library Blocks 


SAT library space is allocated in fixed-length 256-byte blocks formatted as described 
in Table C-1. 


Table C-1. Library Block Format 









Starting with 1 for the initial block, this is the logical block 
sequence number. 


3 This is a binary value less than or equal to 251, indicating the 
number of bytes of relevant record data within the body of this 
block. 

4 

5 - end of block Variabletength records comprising the body of data contained 


in this block (up to 251 bytes). 
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C.2. Library Records 


C2 


Library records within blocks are variable-length records formatted as described in 


Table C-2. 





Variabletength 
record data 


Table C-2. Library Record Format 







Binary value (less than or equal to 249) indicating the length of 
the record data. 





Hexadecimal value indicating the record type (see Table C-3). 


Body of the particular record (up to 249 bytes of data) 









Table C-3. Record-Type Byte Descriptions 


Type Value 
(Hexadecimal) 


02 


03 


07 


09 


OA 


0B 





Description 

Nullified item records 

TEXT/RLD records in object modules 
Transfer records in object modules 
Standard ENTRY records 

Standard EXTRN records 

V-CON records 

Named CSECT records 

Unnamed CSECT records 

Named common records 

Unnamed common records 

Object code ISD records 


continued 
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Table C-3. Record-Type Byte Descriptions (cont) 


Type Value 
(Hexadecimal) 


12 
13 
16 
1¢ 
24 
25 


32 
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Description 

TEXT/RLD records in load modules 

Transfer records in load modules 

Load code ISD records 

Load code ISD records 

Program source or macro/jproc source module records 
Compressed source code item 

Blocked text or RLD records 

Control statement records 

Object module header records 

Load module header/phase header records 
Beginning-of-group ehaicans records 

End-of-file sentinel records 

Macro/jproc name header records (in directory only) 
Macro/jproc module header records 

Program source module header records 
End-of-group demarcator records 

Blocked load module header/phase header records 
Shared code ENTRY (SENTRY) records 

Shared code EXTRN (SEXTRN) records 


Resource records 


C3 
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C.3. Disk Directory 


C.3.1. Directory Blocks 


Table C-4 illustrates the space allocation for a directory block. Each disk file contains 
as many directory blocks as necessary to accommodate all the directory records 
needed to index the file. 


Table C-4. Disk Directory Block Format 





This is the logical block sequence number. 








3 This is a binary value equal to 251. 

4 This is a binary value reflecting an exclusive OR of the bytes in 
the block. 

5-247 Directory records These are 19 directory records, each 13 bytes long (see 







Table C-5 for format). 






Unused 
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C.3.2. Directory Records 


Each directory record is 13 bytes long and is formatted as described in Table C-5. 


Table C-5. Directory Record Format 
















This is an identifier for the module or 
demarcator in the data area which is 
indexed by this directory record. 


This corresponds to the record type of the 
demarcator record in the data area. (See 
Table C-6 for possible values.) 

911 This is the logical block sequence 
number for the data block containing the 
demarcator record. 

12 This is the number of bytes from the 
beginning of the data block to the 
beginning of the demarcator record 
indexed by this directory record. 


Notes: 


1. The block pointer and record pointer values are computed as the data partition is constructed. 


2. The block pointer and record pointer values for a macro module header always identify the beginning of the 
proc module, regardless of where the name directive is contained within the body of the module. 
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Table C-6. Directory Record-Type Values 















Nullified item 
ENTRY name (object module)* 
CSECT name (object module)* 
Object module header 


Phase header (load module) 


SB 8 8 B & 


Beginning-of-group demarcator 


> 
= 


End-of-file sentinal record 
Macro/jproc name* 
Macro/jproc module header 


Program source module header 





End-of-group demarcator 


SB & € BRB 


Block module header record 


* Multiple duplicate names can appear in library file directory. 
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Appendix D 
File Transfer Utility (PCTRAN) 


The file transfer utility (PCTRAN) permits transfer of data files, library modules, and 
source program files between disk or diskette on a Unisys personal computer (PC) and 
disk, diskette, or tape on an OS/3 system. Three user-friendly input screens are used 
to specify the desired file transfer activity, as well as the file names and media 
location used by both the host gomputer and the PC. PCTRAN can also be executed in 
batch mode using an MS-DOS” command (CMD) file. 


D.1. Hardware Requirements 
© PC/HT,™ PCimicro IT,™ or PCIT™ 
¢ UNISCOPE® Communications Board (F4213-02), or Key Ring Adapter 


(F5091-00) and appropriate cable (F8487-00 or F8487-01), or USERNET 
UNISCOPE Protocol Communications Server (3147-xx) 


™ 


D.2. Software Requirements 
¢ MS-DOS Operating System, Release 2.1 or higher 
e Synchronous Terminal Emulation Program (STEP) (F8721-00) with upgrade kit 
(F6166-00), or USERNET UNISCOPE Protocol Communications Server 
(F8743-xx) 


¢ OS/3 Communications Software (ICAM) 


MS-DOS is a registered trademark of Microsoft Corporation. 
PC/HT, PC/micro IT, PC/IT, and USERNET are trademarks of Unisys Corporation. 


UNISCOPE is a registered trademark of Unisys Corporation. 
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D.3. Setup Procedures 


Load the Synchronous Terminal Emulation Program (STEP) into the PC and generate 
the proper UNISCOPE (U20) configuration for the PC. This procedure is described in 
the Unisys Personal Computer Guide to Unisys Terminal Emulator User Guide 
(UP-11886). 


The OS/3 host system must have an ICAM generation with a line and U20 terminal 
defined with the same RID/SID as was specified in the PC configuraiton. The PC can 
be configured as a remote terminal emulating a workstation or as a remote 
workstation. See the ICAM Programming Reference Manual (UP-9749) for OS/3 ICAM 
generation procedures. 


Some examples of OS/3 ICAM generation are: 


CCA Specifications 


REMO LOCAP TYPE=(DMI), IAS=(YES, OFF) ,MODE=SYSTEM 


Line and Terminal Specifications 


LN1@ 
™11 


Tw12 


LN2@ 


TM21 


TM22 


Note: 


D2 


Remote Terminal Emulating a Workstation 


LINE DEVICE=(UNISCOPE) , TYPE=(2480, SWCH, SYNC, UNAT) , ID=18, 
CHAN=15, INPUT=(YES) 

TERM FEATURES=(U2@, 1920) , ADDR=(21,51), TCTUPD=YES, 
LOW=MAIN, MED=MAIN, HIGH=MAIN, AUX1=(COP, 73) 

TERM FEATURES=(U2@, 1920) , ADDR=(21,52) , TCTUPD=YES, 
LOW=MAIN,MED=MAIN, HIGH=MAIN, AUX1=(COP, 73) 


Remote Workstation 


LINE DEVICE=(RWS) , TYPE=(2400, SWCH,UNAT), ID=7,CHAN=15, 
INPUT=(YES) 

PGROUP PGID=23 

TERM FEATURES=(U2@, 1920, , ,PRIMARY) ,ADDR=(23,51), 
LOW=MAIN, MEDIUM=MAIN, HIGH=MAIN, AUX1=(COP, 73) 

TERM FEATURES=(U20, 192@, , ,SECONDARY) ,ADDR=(23,52), 
LOW=MAIN, MEDIUM=MAIN, HIGH=MAIN, AUX1=(COP, 73) 


The AUX1 device is not necessary for this utility and is used only when you 
want to use the PC printer as an auxiliary printer on a workstation. 
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D.4. Operating Procedures 


During the file transfer process (PCTRAN), you can press any function key to 
terminate the file transfer and initiate program restart. In the normal operating 
mode, the transfer terminates when the input end-of-file is detected on either the host 
file or the PC file. To use PCTRAN 


1. 
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Make sure that the OS/3 ICAM is ready, and that the communications line to be 
used is up and available. 


Load the PC using the proper PC configuration generated in the setup procedure. 
For example, if the configuration is defined as RMT, the load entry is 


STEP RMT 


After the PC successfully connects, the word Poll flashes on the right side of 
line 25. 


Note: Sign on is not required if the PC is configured as a remote workstation and 
the line definition in the ICAM generation specifies DEVICE=(RWS); go to 
step 5. 

Sign on to OS/3 using the $$SON command as follows: 


SSSON TM11REMO 


where TM11 is the terminal-ID and REMO is the CCA LOCAP name defined in 
the ICAM generation. 


The OS/3 logo is displayed. You can now log on in the normal manner. After you 
log on, perform step 5a or 5b to enter system mode to initialize PCTRAN. 


a. Ifthe PC is operating as a remote terminal emulating a workstation, 
simultaneously press the ALT and 1 keys to put the PC in emulated system 
mode. 


b. Ifthe PC is operating as a remote workstation, press the ALT and 4 keys 
simultaneously to put the PC in system mode. 


Enter the following command to initialize PCTRAN: 
PCTRAN INDEX=1-8,CMD=dr ive: filename.ext 
where: 
INDEX 
Specifies the terminal index number that determines the logical 
terminal to be used during file transfers and batch mode command file 


processing. This value must be set to the same display number that is 
used to initiate PCTRAN. 
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CMD 
Indicates the PC drive and DOS file name of the command file that 
contains PCTRAN input information for batch operation. See D.5 for 
PC CMD file usage. 


The file transfer utility loads and the mode screen is displayed (see Figure D-1). 
Examples for each mode follow. (See the General Editor (EDT) Operating Guide 
(UP-9976) for additional information.) 


* 08/3 PC FILE TRANSFER UTILITY * 
Version 2R@ 


: Receive Character Data File from Host 
: Transmit Character Data File to Host 
: Receive Hexify Data File from Host 

: Transmit Hexify Data File to Host 

: Terminate PCTRAN 


Select mode : (1) 


NOTE: Depress any function key to terminate transfer and restart. 





Figure D-1. Mode Screen (Screen 1) 
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File Transfer Utility (PCTRAN) 


Example 1: Receive Character Data File from Host 


1. Select mode (1) to Receive Character Data File from Host (see Figure D-1). Press 
the XMIT key to get the host screen (see Figure D-2). 


* OS/3 PC FILE TRANSFER UTILITY* 


RECEIVE DATA FROM HOST 


Enter 0S/3 file specifications in the following format: 

module-name, filename, vsn, SAT=YES 

OR 

FILE=filename, VSN=vsn, RCFM=VAR 
(file=test,vsn=res 
¢ 
See general editor description of file specifications. 
Sample Keywords: MODULE, FILE, VSN, TYPE, DEVICE, SAT 


Note : The OS/3 file default parameter values are as follows: 
DEV=DISK SAT=NO RCFM=F IX 
EXTEND=YES RCB=NO RCSZ=256 
INC=1 INIT=NO SIZE=2 





Figure D-2. Host Screen (Screen 2) 

2. Enter the appropriate host file name, volume serial number (VSN), and other 
parameter options to define the host file. Minimum requirements for a file 
definition are the file name and volume serial number. Figure D-2 shows that file 
name (test) and VSN (res) are specified. 


3. After the host file has been opened, the PC screen (see Figure D-3) is displayed. 


* OS/3 PC FILE TRANSFER UTILITY* 
RECEIVE DATA FROM HOST 
Enter personal computer file specifications : 


PC drive:filename 
(A:testfile.dta ) 


NOTE: File is in the form filename.extension. 





Figure D-3. PC Screen (Screen 3) 
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4. Type in the appropriate PC specifications to define the PC file. Figure D-3 shows 
that drive (a) is specified to contain the PC file name (testfile) and the extension 
(dta). Press XMIT to transfer the host file (test) to the PC file (testfile.dta) located 
on drive (A). 


5. When the file transfer is completed, the mode screen (see Figure D-4) is displayed 
indicating the total record count received from the host file. You can terminate 
PCTRAN or select another file transfer operation. Select mode 2, Transmit 
Character Data File to Host. Press XMIT to begin the next file transfer. 


* OS/3 PC FILE TRANSFER UTILITY*® 


Version 2R0 


: Receive Character Data File from Host 
: Transmit Character Data File to Host 
: Receive Hexify Data File from Host 
: Transmit Hexify Data File to Host 
: Terminate PCTRAN 

Select mode : (2) 


NOTE : Depress any function key to terminate transfer and restart. 


RECEIVE RECORD COUNT = 000050 





Figure D-4. Mode Screen Redisplayed at End of First Successful File Transfer 


Example 2: Transmit Character Data File to Host 
1. Figure D-5 shows the following parameter options selected for the host file: 


a. The record format (rcfm) is defined as variable to omit trailing blanks from 
the last block transferred. 


b. The record size (resz) is 168 characters. 
c. The record control byte (rcb=yes) precedes each record. 


d. Option (key1=1:7) specifies that characters 1 through 7 of the record are key 
fields. 


Note: Specify SAT=YES when you transfer a SAT module to a new host file; 
otherwise, the module is in a MIRAM file format (default). 
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* oS/3 PC FILE TRANSFER UTILITY* 


TRANSMIT DATA TO HOST 
t 
Enter 0S/3 file specifications in the following format: 
module-name, filename, vsn, SAT=YES 
OR 
FILE=fjlename, VSN=vsn,RCFM=VAR 


(file=testout,vsn=res,rcfm=var ,rcsz=168, reb=yes ,key1=1:7 
¢ 


See general editor description of file specifications. 
Sample Keywords: MODULE, FILE,VSN,TYPE,DEVICE, SAT 


Note : The OS/3 file default parameter values are as follows: 
DEV=DISK SAT=NO RCFM=F IX 
EXTENDED=YES RCB=NO RCSZ=256 
INC=1 INIT=NO SIZE=2 





Figure D-5. Host Screen Redisplayed 


2. When the file is opened, the PC screen is displayed again (see Figure D-6). Select 
the PC drive that contains the file you want to transfer to the host; in this 


example, drive (A) and file name (testfile.dta). Press XMIT to execute the file 
transfer. 





* os/3 PC FILE TRANSFER UTILITY* 















TRANSMIT DATA TO HOST 
Enter personal computer file specifications : 


PC drive: filename 
(A:testfile.dta ) 


NOTE: File is in the form filename.extension. 


Figure D-6. PC Screen Redisplayed 


3. When the second transfer is completed, the mode screen (see Figure D-7) is again 
displayed with a new total record count of the records transferred. 
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* oS/3 PC FILE TRANSFER UTILITY* 


Version 2R8 


: Receive Character Data File from Host 
: Transmit Character Data File to Host 
: Receive Hexify Data File from Host 


: Transmit Hexify Data File to Host 
: Terminate PCTRAN 


Select mode : (3) 
NOTE: Depress any function key to terminate transfer and restart. 


RECEIVE RECORD COUNT = 000050 





Figure D-7. Mode Screen Redisplayed at End of Second Successful File Transfer 
Example 3: Receive Hexify Data File from Host 


1. The host file may contain data such as field character control (FCC), null 
characters, etc., that need to be conserved and transferred back to the host intact. 
Select mode 3, Receive Hexify Data File from Host (see Figure D-7), to retain all 
control characters in the host file. Press XMIT to get the host screen. 


2. In Figure D-8, the module (testtext) located in file (datafile) on the host screen, is 
specified for transfer to the PC. Press XMIT to open the files on the host. 


* os/3 PC FILE TRANSFER UTILITY * 
RECEIVE DATA FROM HOST 


Enter 0S/3 file specifications in the following format: 
module-name, filename, vsn, SAT=YES 
OR 
FILE=filename, VSN=vsn, RCFM=VAR 
(testtext, datafile, testvsn 
¢ 
See general editor description of file specifications. 
Sample Keywords: MODULE, FILE, VSN, TYPE, DEVICE, SAT. 


Note: The OS/3 file default parameter values are as follows: 
DEV=DISK SAT=NO RCFM=F IX 
EXTEND=YES RCB=NO RCSZ=256 
INC=1 INIT=NO SIZE=2 





Figure D-8. Host Screen Redisplayed 
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3. When the host file is opened, the PC screen (See Figure D-9) is displayed. 


* OS/3 PC FILE TRANSFER UTILITY * 


RECEIVE DATA FROM HOST 
Enter personal computer file specifications : 


PC drive: filename 
(B:hexdata ) 


NOTE: File is in the form filename.extension. 





Figure D-9. PC Screen Redisplayed 


4. Enter the PC drive to receive the host file (B) and the file name (hexdata). Press 
XMIT to execute the transfer of the host hexify file to the PC. 


5. The mode screen (see Figure D-10) is displayed at the end of the transfer and 
indicates that 75 records were received by the PC. 
* Oos/3 PC FILE TRANSFER UTILITY* 
Version 2Rre 
s Receive Character Data File from Host 
: Transmit Character Data File to Host 
: Receive Hexify Data File from Host 
: Transmit Hexify Data File to Host 


s Terminate PCTRAN 


Select mode : (4) 


NOTE: Depress any function key to terminate transfer and restart. 


RECEIVE RECORD COUNT = 000075 





Figure D-10. Mode Screen Redisplayed at End of Third Successful File Transfer 


6. Select mode 4, Transmit Hexify Data File to Host, and press XMIT to begin the 
next transfer operation. 
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Example 4: Transmit Hexify Data File to Host 


1. The host screen (See Figure D-11) shows that the host module (stepmod) is stored 
in the SAT file (srcfil) located on the RES OS/3 disk pack. If the module name and 
SAT parameter are not included in the host file specification, a MIRAM file 
(srcfil) is stored on the RES OS/3 disk pack. 


*os/3 PC FILE TRANSFER UTILITY* 


TRANSMIT DATA TO HOST 


Enter OS/3 file specifications in the followirig format: 

module-name, filename, vsn, SAT=YES 

OR 

FILE=filename, VSN=vsn, RCFM=VAR 
(stepmod, srcfil,res,sat=yes 
¢ . 
See general editor description of file specifications. 
Sample Keywords: MODULE, FILE,VSN,TYPE,DEVICE ,SAT 


Note: The OS/3 file default parameter values are as follows: 
DEV=DISK SAT=NO RCFM=FIX 
EXTEND=YES RCB=NO RCSZ=256 
INC=1 INIT=NO SIZE=2 





Figure D-11. Host Screen Redisplayed 
2. Press XMIT to open the host file and get the PC screen (see Figure D-12). The PC 
loadable file (step.com) is selected for transfer to the host module (stepmod) from 
PC drive (A). Press XMIT to begin the transfer of data to the host. 


Note: You can receive the host module (stepmod) by another PC at a later time by 
selecting mode 3, Receive Hexify Data File from Host (see Example 3). 


* oS/3 PC FILE TRANSFER UTILITY* 
TRANSMIT DATA TO HOST 
Enter personal computer file specifications : 


PC drive: filename 
(Asstep.com ) 


NOTE: File is in the form filename.extension. 





Figure D-12. PC Screen Redisplayed 
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When the transfer is completed, the mode screen (see Figure D-13) is displayed 
with a now total record count of the records transferred. 
* OS/3 PC FILE TRANSFER UTILITY* 
Version 2R@ 
: Receive Character Data File from Host 


: Transmit Character Data File to Host 
: Receive Hexify Data File from Host 


: Transmit Hexify Data File to Host 
: Terminate PCTRAN 


Select mode : (1) 


NOTE : Depress any function key to terminate transfer and restart. 


RECEIVE RECORD COUNT = 000223 





Figure D-13. Mode Screen Redisplayed at End of Fourth Successful File Transfer 


& Example 5: Receive Character Data File from Host 


1. 


This last example returns to the selection of mode 1 in Figure D-13 to show how 
PCTRAN transfers an OS/3 load module from the host to the PC. Press XMIT to 
get the next screen. 


Figure D-14 shows the parameter (pctran00) specified as a load module and 
module type (1) in the host file ($Y$LOD). Press XMIT to open the host file. 


Note: When a module is received from the host with a module type specified, you must 
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use the same module type (1 or o) when you transmit the module back to the 
host. 
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* o0S/3 PC FILE TRANSFER UTILITY*® 


RECEIVE DATA FROM HOST 


Enter 0S/3 file specifications in the following format: 
module-name, filename, vsn, SAT2YES 
OR 
FILE=f i lename, VSN=vsn, RCFM=VAR 
(pctrane@, $y$lod,res, | 
¢ 
See general editor description of file specifications. 
Sample Keywords: MODULE ,FILE,VSN, TYPE ,DEVICE,SAT 


Note: The 0S/3 file default parameter values are as follows: 
DEV=D1SK SAT=NO RCFM=F IX 
EXTEND=YES RCB=NO RCS2=256 
INC=1 INIT=NO SI2ZE=2 





Figure D-14. Host Screen Redisplayed 


3. When the file has been opened, the PC screen (see Figure D-15) is displayed. 
Drive (B) and file name (pctran.lod) are selected on the PC to receive the host 
data. Press XMIT to begin the transfer. 





Note: During the transfer, the OS/3 module (pctran00) is translated from object code 
in the host file to a PC ASCII data file in (pctran.lod). When the module is 
transferred back to the host, it is once again translated back to object code 
format with () specified as the module type. 


* oS/3 PC FILE TRANSFER UTILITY* 
RECEIVE DATA FROM HOST 
Enter personal computer file specifications : 


PC drive; filename 
(Bspctran-lod  ) 


NOTE: File is in the form filename.extension. 





Figure D-15. PC Screen Redisplayed 
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4. When this transfer is successfully completed, the mode screen (See Figure D-16) 
reappears showing the total record count received at the host computer. 


* OS/3 PC FILE TRANSFER UTILITY* 


Version 2R@ 
: Receive Character Data File from Host 
: Transmit Character Data File to Host 
: Receive Hexify Data File from Host 
: Transmit Hexify Data File to Host 
: Terminate PCTRAN 
Select mode : (5) 


NOTE : Depress any function key to terminate transfer and restart. 


RECEIVE RECORD COUNT = 00@223 





Figure D-16. Mode Screen Redisplayed at End of Fifth Successful File Transfer 
5. After completing the several file transfers described in the preceding examples, 
@ select option 5 to terminate PCTRAN. A final screen (see Figure D-17) is 
displayed when PCTRAN is terminated normally. 
Notes: 


1. IfPCTRAN terminates abnormally, the PC termination screen shown in Figure 
D-17 is not displayed. Interactive services displays an error. 


2. When PCTRAN is initiated from a menu, the PC termination screen is not 
displayed before at termination before returning to menu services. 


* OoS/3 PC FILE TRANSFER UTILITY * 


HAS TERMINATED NORMALLY 





Figure D-17. PCTRAN Termination Screen 
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D.5. Batch Mode 


STEP provides the ability to retrieve commands from an MS-DOS file and transmit 
them to the host computer. The commands are sent in a sequential manner in 
response to information from the host system. 


The PCTRAN user can specify an MS-DOS drive and command file name using the 
CMD parameter. The default file name is the CMDFILE contained on the current 
MS-DOS drive and directory. 


D.5.1. Using STEP CMD File for PCTRAN Batch Mode 


Using EDLIN or an MS-DOS editor, construct a PCTRAN command sequence similar 
to the following example. In this example, the STEP default CMD file name 
CMDFILE is used. Refer to the Terminal Emulator User Guide (UP-11886) for 
information on command file processing. 


Statement ’ Function 

1. x,M,,28 Wait for “(” character in PCTRAN mode 
screen. Set PC menu mode. 

2. >*K2*K> Send 1 to host and transmit. 

3. >AKFILE=xxxx, VSN=yyyy*K*K> Send OS/3 file parameters (xxxx, yyyy) 


and transmit. 


4, >Ka*zzz2*K> Send PC drive A the PC file name (zzzz) 

5. >*K5*K> or >*K2*K> Terminate (5) or next file (2), and 
transmit 

6. X,C, ,@@ Accept any data string for next batch file 


execution, and clear PC menu mode. 


Execution for this example is as follows: press the Ctrl and S keys simultaneously to 
start the CMDFILE. Then key in RV PCTRAN in system mode and transmit. 


Note: Enter “K by pressing the Ctrl and K keys simultaneously. 


D.5.2. Using STEP CMD File for Automatic Terminal Logon 
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Execution of the log on command file can be initiated immediately upon loading 
STEP. Select Y for the “Enable file transfer” and “Start CMDFILE file” options on the 
file transfer options screen of the STEP configuration. 


Note: Enter *K by pressing the Ctrl and K keys simultaneously. 
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File Transfer Utility (PCTRAN) 


Sign on and log on to an OS/3 remote terminal can be accomplished by using the 


following sample command file: 
Statement 
1. X,C,,1e 
2. >$$SON user-id 
or 
>$$open user-id 


3. > OS/3 LOGON IN PROGRESS > 


4. X,M,,3E 


5. >*KUSERIO*K*K*K*KNO*KNO*K*K 


6. x,C,, 08 


Function 

Wait for SOE from host 

OS/3 $$SON user-id 

Telcon $$0PEN user-id 

Wait for logon screen and transmit 


Wait for > in OS/3 logon screen, set PC 
menu mode 


Send logon screen information 


Accept any data string for next batch 
execution, clear PC menu mode 


Note: There are no imbedded spaces in line 5. 


Remote Workstation 


The following sample command file can be used to log on to an OS/3 remote 


workstation: 
Statement 
1. x,c, , 00 


2. R DUMMY,,,"LOGON" 


3. > OS/3 LOGON IN PROGRESS > 


4. X,M,,3E 


5. >*KUSERID*K*K*K*KNO*KNO*K*K 


6. x,c, , 08 
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Function 
Accept any data string 


Wait for DEPRESS TRANSMIT FOR 
LOGON message 


Wait for logon screen and transmit 


Wait for > in OS/3 logon screen, set PC 
menu mode 


Send logon screen information 


Accept any data string for next batch file 
execution, clear PC menu mode 
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Notes: 


1. The word LOGON in line 2 must be in uppercase letters and must be enclosed in 
double quotation marks as shown. 


2. Ifthe CMDFILE is not executed immediately upon loading STEP, line 2 must not 
be used. 


D.6. Error Messages 
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If OS/3 or the PCTRAN program detects an error condition, an error message is 
displayed. Error messages are listed below. 


Message 
Number Meaning/Action 


FTO0O —_— INVALID SPECIFICATION FOR FILE 


A syntax error has been detected in the host or PC specification. Correct the 
error and reenter specification. 


FTOOl PC DISK FULL, TRANSFER NOT COMPLETED 


Another diskette/disk should be used or unnecessary files should be erased 
from the diskette/disk to provide additional file space. 


FT002 PC DISK NOT READY 
Put diskette/disk in ready state. 
FTO03 PC DISK IS WRITE-PROTECTED 


Make sure the correct diskette/disk has been specified. If so, write enable the 
diskette/disk. 


FTO04 PC I/0 ERROR 
A diskette/disk I/O error has occurred. Correct the PC hardware problem. 
FTOO9 PC ERROR-ACK NOT TRANSMITTED TO HOST 


The PC has not transmitted an ACK (acknowledge) status to the host while 
receiving data. The data transfer is questionable. 


FTO10 PC BLOCK SIZE EXCEEDS MAXIMUM 


The PC has transmitted a block of data that exceeds the PC control page 
block size. The data transfer is questionable. 
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Message 
Number 


FTO11 


FTO12 


FT013 


FTO14 


FTO15S 


FT016 
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Meaning/Action 
RECORD SIZE EXCEEDS MAXIMUM 


The record size specified by the host RCSZ parameter is larger than 7680 
characters. Reenter the host specification with valid record size. 


RECORD SIZE EXCEEDS RCSZ, RECORD SPANNED 


A data record larger than RCSZ has been transmitted to the host. The record 
has been spanned over multiple records on the host file at a record size equal 
to RCSZ. 


PC HEXIFY DATA, MODULE TYPE INVALID 


Operator has specified a module type of O or L in the host file specification, 
but has selected hexify data mode transfer. OS/3 object O or load L modules 
must be transferred using character data mode. 


SYSTEM ERROR MNN 


An OS/3 system error has occurred. Refer to the System Messages Reference 
Manual (UP-8076) for an explanation of this error. 


INVALID TERMINAL INDEX VALUE 


An incorrect value has been specified for the IND=n parameter. Manually 
set the terminal index field of the control page to the correct screen number , 
or terminate PCTRAN and reenter the parameter with the correct screen 
number. 


INVALID MODIFIER 
An incorrect value has been specified for the CMD parameter. Manually set 


the CMDFILE field of the control page, or terminate PCTRAN and reenter 
the parameter. 
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D.7. User Guidelines 


The following guidelines apply to PCTRAN: 


¢ = The file transfer utility (PCTRAN) supports character and PC hexify mode data 
transmission; these modes are selected by the user. When using character mode, 
packed decimal fields and binary control characters within the data cannot be 
transferred and are converted to spaces. The EBCDIC characters that represent 
these control characters are 


00 through 07 
09 through 1A 
1C through 22 
24 through 27 
2A 

2D through 2F 
32 

34 through 37 
3C through 3D 
3F 


¢ When using hexify mode, the data is translated by the PC terminal emulation 
software and by PCTRAN during the file transfer. This option allows you to 
transfer PC object code and binary data to and from the OS/3 host system. 

e 6 If transferring OS/3 object, load, or screen format modules to the PC, the data is 
translated by PCTRAN and is maintained on the PC as character data. When the 
module is transmitted back to the host system, it is translated to OS/3 object code 
format. This facility is activated whenever the host type parameter specifies O, L, 
F, FC, or Menu. 


© Data base files can require formatting to sequential format prior to using 
PCTRAN. 


¢ The maximum record size that can be transferred is 8192 characters. 


e Ifyou initiate a PCTRAN data transfer and the transfer is not completed (the 
mode screen is not redisplayed with a record count), do the following: 


1. Retrieve the STEP control page (press and hold the ALT key and then press 
the 3 key) to see if an error message is displayed. 


2. Press any function key to display the mode screen menu. 
3. Take the necessary corrective action (see the list of error messages). 


4, Reinitiate the data transfer. 
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ALIB keyword paramter, 6-7 
Allocation map 
description, 7-7, (figure) 7-8 
PARAM control statement, 6-12 
Allocation parameter, FILE statement, 12-48 
Alternate tracks 
assigning (ATT routine), 10-1 
testing areas, 9-5 
ALTRK keyword, 9-4, 9-5 
ASGPR keyword, 10-2, 10-3 
ASGTK keyword, 10-2 
Assign alternate track (See ATT routine) 
ASUPD keyword, 10-2, 10-3 
ASURF keyword, 10-2, 10-3 
ATT routine 
description, 10-1 
executing, 10-5 
interfacing with DSKPRP, 10-2 
patching or modifying existing records, 
10-3 
printing records, 10-3 
specifying defective tracks, 10-2 
specifying disk volume serial number, 
10-4 
specifying options, 10-2 
testing alternate track, 10-3 
AUTO keyword parameter, 6-10 
Automatic deletion processing, 4-26 
Automatic inclusion processing, 4-23, 6-7, 
6-10 
Automatic overlay control processing, 4-29 
Automatic terminal logon, STEP CMD file, 
D-14 
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Batch environment 
disk copy routine (SU$CSL), 15-8 
disk copy routine (SU$C16), 15-11 
disk copy routine (SU$C19), 15-4 
DMPERST routine, file mode, 12-35 
DMPRST routine, volume mode, 12-23 
file transfer utility, D-14 
Beginning-of-group demarcator records, B-2 
Beginning-of-group header record format 
(table) B-3 
BGAD parameter 
SU$CSL routine, 15-19 
SU$C16 routine, 15-11 
SU$C19 routine, 15-5 
BLK librarian control statement, SAT, 3-51 
Block length, optional selection, 2-19 
Block load code sets 
description, B-18 
directory entry, (table) B-18 
module header record, (table) B-18 
nonphase text/RLD record, (table) B-21 
RLD mask, (table) B-21 
RLD record, (table) B-20 
transfer record (table) B-22 
Blocks 
directory, C-4 
library, C-1 
BOG librarian control statement, SAT, 3-65 
Buffer analysis routine, 17-1 
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Canned job control streams 
COPYREL, A-3 
disk/diskette prep, 9-35 
librarian, 3-87 
listing, (table) A-1 
referencing, A-1 
SETREL, A-3 
SMCLIST, 13-1 
Card functions, system utility symbiont, 16-1 
Card libraries, SAT librarian, 2-8, 2-22 
Card modules, sequencing, 3-13 
Cards 
adding modules from, 3-11 
copying to a disk file, 3-111 
delimiter, 3-11 
CHG librarian control statement, MIRAM, 
3-85 
CHGVSN/CGV routine, 9-36 
CLIB keyword parameter, 6-7 
CMT keyword parameter, 6-8 
CNTCD keyword parameter, 6-11 
Code, program, 2-8 
Code, shared (See Shared code processing) 
Code set components 
block load code sets B-18 
grouped code sets, B-2 
load code sets, B-13 
object code sets, B-5 
source module code sets, B-4 
summary, B-1 
COM librarian contro] statement, SAT, 3-24 
Comments, changing in module header 
record, 3-85 
Common storage processing, 4-26, 6-10 
Compressed source module code statement 
record format, (table) B-6 
Constants, shared, 4-39 
Contingency error processing, 1-7 
Control section 
linkage editor, 5-1, 5-2 
object code, record format, (table) B-7 
record types, (table) B-7 
Control statement record format, object code, 
(table) B-12 
Control statements 
INSERT, 9-18 
linkage editor (See Linkage editor control 
statements) 
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linkage editor, inseting in object modules, 
3-73 
MIRAM librarian (See MIRAM librarian 
control statements) 
SAT librarian (See SAT librarian control 
statements) 
Control streams 
building from a workstation, 1-9 
multiphase load module, (figure) 4-15 
(See also job control streams) 
multiregion load module, (figure) 4-20 
Control unit address, model 8 through 20 
IMPL, 9-28 
COP librarian control statement 
copying modules and files, 3-16, 3-79 
listing or punching modules, 3-62 
printing sequential table of contents, 3-60 
resetting a file pointer, 3-7 
SAT, 3-8 
COPY parameter 
SU$CSL routine, 15-9 
SU$C16 routine, 15-11 
SU$C19 routine, 15-4 
Copy procedures 
disk, 12-2, 12-5 
disk, file mode, 12-38 
disk, volume mdoe, 12-25 
diskette, file mode, 12-56 
diskette, volume mode, 12-35 
files in single-disk environment, 12-57 
tape, volume mode, 12-25 
tape and diskette, 12-3 
Copy routines 
disk, 8416/8418, 15-7 
disk, 8419, 15-1 
disk, 8430/8433, 15-15 
diskette, 14-1 
system utilities, functions, 1-6 
COPYREL routine, 9-44, A-3 
COR librarian control statement, SAT, 3-33, 
3-47 
CSECTs 
automatic deletion processing, 4-26 
partial INCLUDE processing, 4-36 
CUADR keyword, 9-22, 9-28 
Cylinder address, beginning, 15-5, 15-11 
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Data files, transfer (See File transfer utility) 
Data records, disk libraries, 2-5 
Data set labels 
initializing, 9-28 
mode, 9-23 
DEF keyword parameter, 6-12 
Defect skip table, 9-29 
Defective tracks 
assign alternate (See ATT routine) 
recording, 9-7 
specifying, 10-2 
(See also tracks) 
Definitions 
allocation map, 6-12 
standard references, 4-31 
Definitions dictionary 
description, 7-3 
information characters, (table) 7-5 
PARAM control statement, 6-11 
phase field, (table) 7-5 
type identifications, (table) 7-4 
typical listing, (figure) 7-4 
DEL keyword parameter, 6-12 
DEL librarian control statement 
MIRAM, 3-83 
SAT, 3-20 
Deletion processing, automatic, 4-26 
Delimiter cards, 3-11 
Delimiter records, disk libraries, 2-6 
Density, diskette, 9-24 
DICT keyword parameter, 6-11 
Directory, disk 
block format, (table) C-4 
record format, (table) C-5 
record-type values, (table) C-6 
Directory blocks, disk, C-4 
Directory entry, block load code sets, (table) 
B-18 
Directory operation, (figure) 2-7 
Directory records, disk libraries, 2-6 
Directories 
disk file, printing disk display, 3-90 
printing listings, 3-81 
release volume, printing, 3-87 
update, directories, 3-92 
Disk 
copy in file mode, 12-37 
copy in volume mode, 12-25 
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copy operation, 12-2, 12-5 
copy routine, 8416/8418, 15-7 
copy routine, 8419, 15-1 
copy routine, 8430/8433, 15-15 
dump/restore (See DMPRST routine) 
prep (See DSKPRP routine) 
Disk directory 
block format, (table) C-4 
record format, (table) C-5 
record-type values, (table) C-6 
Disk files 
adding modules from cards, 3-11 
copying cards, 3-111 
MIRAM, dumping to in file mode, 12-44 
MIRAM, dumping to in volume mode, 
12-29 
MIRAM, restoring from in file mode, 
12-55 
MIRAM, restoring from in volume mode, 
12-33 
printing a disk display of a directory, 3-90 
rearranging modules, 3-93 
SAT librarian, 2-3, 2-18 
Disk functions, system utility symbiont, 16-2 
Disk libraries 
data records, 2-5 
directory records, 2-6 
space allocation, 2-5 
structural levels, 2-3, (figure) 2-4 
system and user disk files, 2-3 
Disk utilities 
DSKPRP (See DSKPRP routine) 
functions, 1-5 
Diskette files 
adding modules from cards, 3-11 
SAT librarian, 2-22 
Diskette functions, system utility symbiont, 
16-2 
Diskette libraries, 2-7 
Diskette utilities 
DSKPRP (See DSKPRP routine) 
functions, 1-5 
Diskettes 
copy in file mode, 12-56 
copy in volume mode, 12-35 
copy operation, 12-3 
copy routine (SU$CPY), 14-1 
density, 9-24 
dumping to disk to diskette, 12-28, 12-43 
dump/restore (See DMPRST routine) 
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file allocation, 9-24 

format, 9-23 

initializing data set labels, 9-28 
lacing records, 9-25 

prep (See DSKPRP routine) 

record size, 9-24 

restoring from diskettes, 12-32, 12-53 
spiraling records, 9-25 


DMPRST routine 


checking for file expiration date, 12-63 

copying files in single-disk environment, 
12-57 

description, 12-1 

differences between interactive and batch 
methods, (table) 12-1 

disk copy in file mode, 12-37 

disk copy in volume mode, 12-25 

disk copy procedure, 12-2, 12-5, 12-25 

diskette copy, 12-3 


restoring from diskettes in volume mode, 
12-32 

restoring from MIRAM disk file in file 
mode, 12-55 

restoring from MIRAM disk file in volume 
mode, 12-33 

restoring from tape in volume mode, 12-31 

restoring from tape to single-disk volume 
in file mode, 12-50 

restoring multiple disks from tape in file 
mode, 12-52 

tape copy in volume mode, 12-34 

tape copy operation, 12-3 

using allocation parameter to control 
restore processing, 12-48 

using file prefix parameter, 12-48 

using new-name parameter, 12-49 

volume mode PARAM statements, (table) 
12-24 








DNSTY keyword, 9-22, 9-24 
DRDP canned job control stream, 3-90 
DSKPRP routine 


diskette copy in file mode, 12-56 
diskette copy in volume mode, 12-35 


dump in file mode, 12-39 

dump in volume mode, 12-26 

dump operation, 12-8, 12-26 

dump/restore procedure, 12-3 

dumping disk to tape in file mode, 12-40 

dumping to diskettes in file mode, 12-43 

dumping to diskettes in volume mode, 
12-28 

dumping to MIRAM disk file in file mode, 
12-44 

dumping to MIRAM disk file in volume 
mode, 12-29 

executing in file mode (batch), 12-35 

executing in interactive environment, 12-4 

executing in volume mode (batch), 12-23 

file mode PARAM and FILE statements, 
(table) 12-36 

global file allocation parameters, 12-50 

list operation, 12-21 

listing files on input medium, 12-64 

procedures, 12-2 

restarting, 12-58 

restarting diskette dump/restore, 12-58 

restarting tape dump/restore, 12-61 

restore operation, 12-14 

restore operation in file mode, 12-47 

restore operation in volume mode, 12-31 

restoring from diskette in file mode, 12-53 
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assigning alternate tracks/sectors 
(INSERT), 9-18 

canned job control streams, 9-35 

changing volume serial number, 9-7, 9-23, 
9-36 

checking file expiration date, 9-18, 9-26 

control unit address, IMPL, 9-28 

copy system/release file, 9-44 

creating standard volume labels (VOL1), 
9-19 

description, 9-1 

diskette density, 9-24 

diskette prep options, 9-21 

diskette record size, 9-24 

disks supported, 9-1 

error processing, 9-46 

executing, 9-29 

extent of prep, 9-9 

file allocation for DSL diskettes, 9-24 

indicating diskette format, 9-23 

indicating diskette is IPL volume, 9-26 

initializing data set labels, 9-28 

interface with ATT routine, 10-2 

lacing records to reduce latency time, 9-25 

loading IMPL to diskette, 9-25 

partial prep or building a new 
VOL1/VTOC, 9-8, 9-27 
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prep and allocate RELEASE/SYSRES 
files, 9-41 
prep options, 9-4 
prepping a disk, 9-2 
prepping a disk as IPL volume, 9-5 
recording defective tracks, 9-7 
replacing an IMPL or IPL, 9-7, 9-23 
sample control streams, 9-29 
specifying IMPL module type written to 
diskette, 9-28 
specifying volume serial number, 9-10, 
9-23 
specifying where prep starts and ends, 
9-10 
spiraling records to reduce latency time, 
9-25 
testing alternate track areas, 9-5 
testing an area before prepping, 9-17 
track condition table, 9-10 
typical printout, (figure) 9-11 
VTOC address, 9-16, 9-26 
Dump operation, disk, 12-8, 12-26, 12-39 
(See also DMPRST routine) 
Dump/restore, disk (See DMPRST routine) 
Dynamic buffers, 17-1 


E 


EDAD parameter 
SU$CSL routine, 15-19 
SU$C16 routine, 15-12 
SU$C19 routine, 15-5 
8416/8418 disk copy routine, 15-7 
8419 disk copy routine, 15-1 
8430/8433 disk copy routine, 15-15 
ELE librarian control statement, SAT, 3-11 
Embedded control statements, linkage editor, 
6-3 
End-of-file sentinel record format, (table) B-3 
End-of-group demarcator records, B-2 
End-of-group trailer record format, (table) 
B-3 
ENTER control statement, 4-6, 6-18 
Entry point table, 4-31 
ENTRY points, automatic deletion 
processing, 4-26 
EOD librarian control statement, SAT, 3-11, 
3-33, 3-47, 3-69 
EOG librarian control statement, SAT, 3-65 
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EQU control statement, 4-6, 6-19 
ERR keyword parameter, 6-11 
Error count list, link-edit map, 7-9 
Error legend, link-edit map, 7-9 
Error messages 
PCTRAN, D-16 
SAT librarian, 2-14 
Error processing, prep routine, 9-46 
Errors, program, 1-6 
ESC librarian control statement, SAT, 3-74 
ESD record 
format, (table) B-8 
types, (table) B-8 
Exclusive references, phases, 4-17 
Expiration date (See File expiration date) 
EXTRNs 
allocation map, 6-13 
shared-code environment, (figure) 4-38 
shared records, 4-40 
unresolved, reference list, 7-3 


F 


FDATA keyword, 9-22, 9-24 
File allocation, diskette, 9-24 
File expiration date 
DSKPRP routine, 9-18, 9-26 
DMPRST routine, 12-63 
SU$C19 routine, 15-6 
SU$CSL routine, 15-19 
SU$C16 routine, 15-12 
FIL librarian control statement 
MIRAM, 3-77 
SAT, 3-4 
File mode, DMPRST routine 
copying files in single-disk environment, 
12-57 
description, 12-35 
disk copy operation, 12-37 
diskette copy, 12-56 
dump operation, 12-39 
dumping a disk to tape, 12-40 
dumping diskettes, 12-43 
dumping MIRAM disk file, 12-44 
dumping multiple disks to tape, 12-42 
global file allocation parameters, 12-50 
PARAM statements, (table) 12-36 
restore operation, 12-47 
restoring from diskettes, 12-53 
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restoring from MIRAM disk file, 12-55 
restoring from tape to single-disk volume, 
12-50 
restoring multiple disks from tape, 12-52 
using allocation parameter to control 
restore processing, 12-48 
using file prefix parameter, 12-48 
using new-name parameter, 12-49 
File names, logical, assigning, 3-4, 3-77 
File position pointer, current, 2-22 
File statements 
DMPRST routine, file mode, (table) 12-36 
restore in file mode, 12-47 
File transfer utility (PCTRAN) 
batch mode, D-14, 
description, D-1 
error messages, D-16 
hardware requirements, D-1 
operating procedures, D-3 
setup procedures, D-2 
software requirements, D-1 
user guidelines, D-18 
Files 
comparing, 3-28 
compressing, 3-57 
copying, 3-16, 3-79 
copying in single-disk environment, 12-57 
deleting modules, 3-20, 3-83 
disk (See Disk files) 
dump/restore (See DMPRST routine) 
expiration date, 9-18, 9-26, 12-63 
library, 1-2, 2-3 
listing on input medium, 12-64 
module groups, 3-64 
printing table of contents, 3-58 
RELEASE/SYSRES, prep and allocate, 
9-41 
renaming new-name parameter, 12-49 
resetting pointers, 3-7 
SAT librarian, 2-8 
system/release, copying, 9-44 
tape (See Tape files) 
Format label diskette 
functions, system utility symbiont, 16-2 
(See also diskettes) 
Format label mode, 9-23 
FORMT keyword, 9-22, 9-23 
FRMTG keyword, 9-4, 9-10 
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Global file allocation parameters, 12-50 
Group header records, 2-11 
(See also header records) 
Grouped code sets, B-2 
Groups, module 
building, 3-65, 3-106 
operations, 3-67 
renaming, 3-54 
working with, 3-64 


H 


Hardware utilities 
description, 1-6 
menu, 12-4, 12-5 

Header labels, 2-19 

Header records 
block load module, (table) B-18 
changing comments, 3-85 
format, MIRAM, (table) 2-26 
group, SAT, 2-11 
grouped code sets, B-3 
module, SAT, 2-11 
object module format, (table) B-6 


ILOPT keyword 
disk, 9-4, 9-5, 9-7 
diskette, 9-22, 9-25 
INCLUDE control statement 
automatic inclusion, 4-24 
description, 4-6, 6-15 
partial INCLUDE processing, 4-36 
Inclusion processing, automatic, 4-23 
Inclusive reference, phases, 4-17 
Initial microprogram load (IMPL) 
disk prep, 9-5, 9-7 
diskette prep, 9-23 
loading to diskette, 9-25 
specifying module type written to a 
diskette, 9-28 
Initial program load (IPL) 
disk prep, 9-5, 9-7 
diskette prep, 9-23, 9-26 
INSERT control statement, 9-18 
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INSRT keyword, 9-4, 9-7 
Interactive dialogs, DMPRST routine, 12-4 
Interactive environment 
disk copy routine, 8416/8418 (SU$C16), 
15-7 
disk copy routine, 8419 (SU$C19), 15-1 
disk copy routine, 8430/8433 (SU$CSL), 
15-15 
DMPRST routine, 12-4 
Internal symbol dictionary (ISD) 
PARAM control statement, 6-14 
processing, 4-42 
IPLDK keyword 
disk, 9-4, 9-5, 9-7 
diskette, 9-22, 9-26 
ISD keyword parameter, 6-14 
ISD record format 
load code, (table) B-16 
object code, (table) B-9 


J 


Job control 
MIRAM librarian, 2-27 
SAT librarian, 2-13 
SU$C16 interface, 15-12 
SU$C19 interface, 15-6 
Job control dialog, using workstations, 1-9 
Job control streams 
assign alternate track (ATT) routine, 10-5 
canned, disk/diskette prep, 9-35 
canned librarian, 3-87 
executing disk prep, 9-29 
linkage editor, 8-1 
SMCLIST, 13-1 
Jproc source modules, 2-9 


L 


Label definitions 
EQU control statement, 6-19 
referencing in a load module, (figure) 4-25 
Label initializing function, 9-2 
Labels, standard volume, 9-19 
LACEG keyword, 9-22, 9-25 
Lacing records, diskette, 9-25 
Latency time, reducing, 9-25 
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Librarian maps 


controlling page advancement, 3-10 

file compare, (figure) 3-30 

MIRAM, 2-30 

sample, building module groups, 3-108 

sample, copying cards to a disk file, 3-113 

sample, repositioning modules, (figure) 
3-96 

sample, sorting modules by type, 3-103 

SAT, 2-14 

source module compare, (figure) 3-27 


Librarians 


canned job control streams, 3-87 

control statements, MIRAM (See MIRAM 
librarian control statements) 

control statements, SAT (See SAT 
librarian control statements) 

description, 1-2, 2-1 

MIRAM (See MIRAM librarian) 

SAT (See SAT librarian) 


Libraries 


card, 2-8 

copying release or SYSRES, A-3 
disk, 2-3 

diskette, 2-7 

MIRAM (See MIRAM librarian) 
SAT (See SAT librarian) 
structure, SAT, C-1 

system (See System librarian) 
tape, 2-7 


Library files, 1-2 
LIBS (See SAT librarian) 
Link-edit map 


allocation map, 7-7 

definitions dictionary, 7-3 
description, 7-1 

error count list, 7-9 

error legend, 7-9 

PARAM control statement, 6-11 
phase structure diagram, 7-6 
process map, 7-1 

programming examples, 8-1 
unresolved EXTRN reference list, 7-3 
UPSI setting, 7-9 


Linkage editor 


automatic deletion processing, 4-26 
automatic inclusion processing, 4-23 
automatic overlay control processing, 4-29 
begin load module, 6-14 

begin new region, 6-17 
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begin overlay phase, 6-16 

capabilities, 1-4 

common storage processing, 4-26 

control section dependencies, 5-2 

control statement functions, 4-5 

control statements (See Linkage editor 
control statements) 

define label, 6-19 

define phase execution entrance, 6-18 

description, 1-4, 4-1 

include object code, 6-15 

inputs and outputs, 4-3 

internal symbol dictionary, 4-42 

link-edit maps (See Link-edit map) 

load module format, 4-8 

load module structure, 4-13 

modify location counter, 6-20 

multidefinition resolution processing, 4-31 

multiregions, 5-2 

object module format, 4-7 

operation, 4-22 

partial INCLUDE processing, 4-36 

phase dependencies, 5-2 

phase origins and node points, 5-2 

program examples, 8-1 

program length, 5-2 

program overlay structures and 
dependencies, 5-1 

reserve storage, 6-22 

SAT interface, 4-2 

shared code processing, 4-36 

specifying options, 6-5 

temporary storage usage, 4-3 

user program switch indicator setting, 
4-45 

Linkage editor control statements 

basic processing, 6--3 

coding format, 6-1 

description, 6-1 

embedded, 6-3 

ENTER, 6-18 

EQU, 6-19 

functions, 4-5 

INCLUDE, 6-15 

inserting in object modules, 3-69 

LINKOP, 6-5 

LOADM, 6-14 

MOD, 6-20 

OVERLAY, 6-16 

PARAM, 6-5 
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placement, 6-2 
REGION, 6-17 
RES, 6-22 
LINKOP control statement, linkage editor, 
4-5, 6-5 
LIST keyword parameter, 6-11 
List operation, DMPRST routine, 12-21 
List options, link-edit map, 6-11 
List software maintenance corrections 
(SMCLIST), 1-6, 13-1 
Listings, printing, 3-81 
LISTRES, command job control stream, 3-87 
Load code sets 
block (See Block load code sets) 
description, B-13 
ISD record format, (table) B-16 
phase definition record format, B-13 
shared code record format, (table) B-15 
text/RLD record format, (table) B-16 
transfer record format, (table) B-17 
Load modules 
automatic inclusion, 4-23 
automatic overlay control processing, 4-29 
begin, LOADM contro] statement, 6-14 
blocking, 3-51 
code sets, B-13 
common storage processing, 4-26 
communications between phases, 4-17 
correcting, 3-47 
defining program entry point, 6-18 
description, 2-10 
format, 4-8 
internal symbol dictionary, 4-42 
linkage editor, 1-4, 4-1, 6-8 
multiphase, 4-13 
multiregion, 4-19, 5-2 
node points and paths, 4-16 
partial INCLUDE processing, 4-36 
phase definitions, 4-15 
reentrant, 6-13 
referencing label definitions, (figure) 4-25 
regions, 6-17 
reserve additional storage, 6-22 
shared code processing, 4-36 
single-phase, 4-13 
structure, 4-13 
(See also Modules) 
LOADM control statement, 4-6, 6-14 
Location counter, modifying, 6-20 
Logical file names, assigning, 3-4, 3-77 
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LST librarian control statement, SAT, 3-58 


Macro source modules, 2-9 
Main storage 
allocating for SAT librarian, 2-17 
’ requirements, effects of shared code, 
(figure) 4-37 
Map (See Librarian map) 
MIRAM disk files 
dumping from, volume mode, 12-32 
dumping to, file mode, 12-44 
dumping to, volume mode, 12-29 
restoring from, file mode, 12-55 
restoring from, volume mode, 12-33 
MIRAM librarian 
canned job control streams, 3-87 
capabilities, 2-25 
control statements (See MIRAM librarian 
control statements) 
description, 1-2, 2-1 
file allocation and management, 2-25 
map, (figure) 2-30 
multifile tape creation, 2-31 
module creation, 2-26 
module header record format, (table) 2-26 
module management, 2-27 
module structure, 2-25 
printing a directory of a release volume, 
3-87 
printing a disk display of a disk file 
directory, 3-90 
printing listings of modules in system 
libraries of release volume, 3-91 
using, 2-27 
MIRAM hbrarian control statements 
CHG, 3-85 
COP, 3-79 
DEL, 3-83 
description, 3-1, 3-77 
FIL, 3-77 
format conventions, 3-1 
PRT, 3-81 
summary, (table) 3-77 
MLIB (See MIRAM librarian) 
MOD control statement, 4-7, 6-20 
MODLST canned job control stream, 3-91 
Modules 
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adding from cards, 3-11 

blocking, 3-51 

card, sequencing, 3-13 

changing names and comments, 3-85 

code sets (See Code set components) 

compressing a file, 3-57 

control statement requirements for 
processing, (table) 2-23 

copying, 3-16, 3-79 

correcting, 3-33 

current file position pointer, 2-22 

date and time of creation, 2-16 

deleting, 3-20, 3-83 

disk libraries, 2-3 

general operations, 2-9 

groups, 2-11, 3-64, 3-106 

header records, 2-11 

jproc source, 2-9 

linkage editor SAT interface, 4-2 

listing and punching, 3-61 

load (See Load modules) 

macro source, 2-9 

MIRAM, creation, 2-26 

MIRAM, header record format, (table) 
2-26 

MIRAM, management, 2-27 

MIRAM, structure, 2-25 

naming conventions, 2-11 

object (See Object modules) 

printing fields before correction, 2-24 

printing file table of contents, 3-58 

printing listings, 3-81, 3-91 

program library files, 1-2, 2-2 

program source, 2-9 

rearranging in a disk file, 3-93 

renaming, 3-54 

resetting pointers, 3-7 

sequencing and resequencing, 3-22 

sorting into separate files, 3-101 

source, comparing, 3-24 

transferring, D-1 

types, 2-8 
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Multidefinition resolution processing 
description, 4-31 
V-CON references, 4-34 
with V-CON references, (figure) 4-35 
without V-CON references, (figure) 4-33 
Multifile tapes 
MIRAM librarian, 2-30 
SAT librarian, 2-20 
Multiphase load modules 
description, 1-4, 4-13 
phase structure diagram, 7-6 
Multiregion load modules, 1-4, 4-19, 5-2, 
(figure) 5-3 


N 


NOAUTO keyword parameter, 6-10 
NOCNTCD keyword parameter, 6-11 
Node points, linkage editor, 4-16, 5-12 
NODEF keyword parameter, 6-12 
NODEL keyword parameter, 6-12 
NODICT keyword parameter, 6-11 
NOERR keyword parameter, 6-11 
NOISD keyword parameter, 6-14 
NOLIST keyword parameter, 6-11 
Nonphase text/RLD record, (table) B-21 
NOPHS keyword parameter, 6-12 
NOPROM keyword parameter, 6-10 
NORCNTCD keyword parameter, 6-12 
NOREF keyword parameter, 6-13 
NORNT keyword parameter, 6-13 
NOSHARE keyword parameter, 6-13 
NOV keyword parameter, 6-10 


0 


Object code sets 
control section record format, (table) B-7 
control section record types, (table) B-7 
control statement record format, (table) 

B-12 

description, B-5 
ESD record format, (table) B-8 
ESD record types, (table) B-8 
header record format, (table) B-6 
ISD record format, (table) B-9 
relocation mask field, (figure) B-11 
relocation mask format, (table) B-14 
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text/RLD record format, (table) B-9 
transfer record format, (table) B-12 
Object modules 
automatic inclusion, 4-23 
code sets (See Object code sets) 
correcting, 3-47 
description, 2-9 
embedded linkage editor contro] 
statements, 6-3 
format, linkage editor, 4-7 
headers, link-edit map, 6-12 
INCLUDE control statement, 6-15 
inserting linkage editor control 
statements, 3-69 
internal symbol dictionary, 4-42 
reentrant, 6-13 
(See also modules) 
Options, linkage editor, 6-5 
OUT keyword parameter, 6-8 
OVEF parameter 
SU$CSL routine, 15-19 
SU$C16 routine, 15-11 
SU$C19 routine, 15-5 
Overlay control processing, automatic, 4-29 
Overlay control routine, 4-29, 4-30 
OVERLAY control statement, 4-6, 6-16 
Overlay structures, linkage editor, 5-1 


P 


PAC librarian control statement, SAT, 3-57 
PACKRES canned job control stream, 3-92 
Page advancement, librarian map, 3-10 
PAGE librarian control statement, SAT, 3-10 
PARAM control statement 
executing DMPRST in file mode, 12-35 
executing DMPRST in volume mode, 12- 
23 
linkage editor, 4-5, 6-5 
MIRAM librarian, 2-31 
SAT librarian, 2-16, 2-24 
SU$CSL disk copy routine, 15-18 
SU$C16 disk copy routine, 15-11 
SU$C19 disk copy routine, 15-4 
Partial INCLUDE processing, 4-36 
PARTL keyword 
disk, 9-4, 9-8 
diskette, 9-22, 9-27 
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Paths 
load module, 4-17 
multidefinition resolution processing, 4-31 
PCTRAN (See File transfer utility) 
Phase definition record format, (table) B-13 
Phase field, definitions dictionary, 7-3, (table) 
7-5 
Phase structure diagram, link-edit map, 
6-11, 7-6 
Phase table (PTAB), 4-31 
Phases 
automatic deletion processing, 4-26 
automatic overlay control processing, 4-29 
communications, 4-17 
defining execution entrance, 6-18 
definitions, load module, 4-15 
dependencies, 5-2 
inclusive and exclusive references, (figure) 
4-18 
listing data in link-edit map, 6-12 
names, load module, 4-16 
origins and node points, 5-2 
segments of an overlay program, 5-1 
PHS keyword parameter, 6-12 
Pointer 
current file position, 2-22 
resetting in a file, 3-7 
resetting past a module, 3-8 
Prep routines, disk/diskette (See DSKPRP 
routine) 
PREPT keyword, 9-4, 9-9 
PRNT parameter 
SU$CSL routine, 15-19 
SU$C16 routine, 15-11 
SU$C19 routine, 15-4 
Process map 
description, 7-1 
listing, (figure) 7-2 
messages, (table) 7-2 
PARAM control statement, 6-11 
Program code, types, 2-8 
Program error checking, 1-6 
Program library, 1-2 
Program modules, 
SAT librarian, 1-2, 2-2, 2-8 
(See also modules) 
Program source modules, 2-9 
Programming examples 
disk copy routine, 8416/8418, 15-13 
disk copy routine, 8419, 15-6 
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disk copy routine, 8430/8433, 15-20 
diskette copy routine, 14-3 
linkage editor, 8-1 
SAT librarian, 3-93 
Programs 
defining entry point, 6-18 
linkage editor, 5-1 
PROM keyword parameter, 6-10 
PRT librarian control statement, MIRAM, 
3-81 
PTBEG keyword, 9-4, 9-10 
PTEND keyword, 9-4, 9-10 





R 


RCNTCD keyword parameter, 6-12 
Records 

block load code sets, B-18 

code set components, B-1 

directory record format, (table) C-5 

disk libraries, 2-3, 2-5 

existing, patching or modifying, 10-3 

grouped code sets, B-2 

internal symbol dictionary, 4-42 

lacing, 9-25 

library record format, C-2 

load code sets, B-13 

module and group header, 2-11 

object code sets, B-5 

printing, ATT routine, 10-3 

rearranging, (figure) 3-46 

renaming, 3-54 

replacing and inserting, 3-40 

sequencing, 3-22 

shared, 4-40 

size, diskette, 9-24 

skipping, 3-42 

source module code sets, B-4 

spiraling, 9-25 

transfer, 6-13 
RECSZ keyword, 9-22, 9-24 
Reentrant code (See Shared code processing) 
Reentrant load module, 4-40, 4-41 
REF keyword parameter, 6-13 
Reference, phases 

inclusive and exclusive, 4-17, (figure) 4-18 

standard, 4-31 
REGION control statement, 4-6, 6-17 
Region table (RTAB), 4-31 
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Release libraries, copying, 9-44, A-3 
Release volumes 
compressing, 3-92 
printing a directory, 3-87 
printing listings of modules, 3-91 
SETREL routine, 9-41, A-3 
Relocation mask 
field, (figure) B-11 
format, (table) B-10 
Remote terminal, PCTRAN in batch mode, 
D-14 
REN librarian control statements, SAT, 3-54 
REPRO librarian control statement, SAT, 
3-69 
RES control statement 
linkage editor, 6-22 
SAT librarian, 3-7 
Reserve storage, 6-22 
Resolution processing, multidefinition, 4-31 
Restore operation, disk 
file mode (batch environment) 12-47 
interactive environment, 12-14 
procedure, 12-3 
volume mode (batch environment), 12-47 
(See also DMPRST routine) 
RETRY keyword, 9-4, 9-9 
RLD mask, (table) B-21 
RLD record format 
block load code, (table) B-20, (table) B-21 
load code, (table) B-16 
object code, (table) B-9 
RLIB keyword parameter, 6-8 
RNT keyword parameter, 6-13 
Routines (See System utilities) 
RPVOL keyword 
disk, 9-4, 9-7 
diskette, 9-22, 9-23 


S 


SAT librarian 

adding logical file names, 3-4 

adding modules from cards to disk, tape, 
or diskette files, 3-11 

allocating additional main storage, 2-17 

assigning version numbers to modules, 
2-24 

blocking load modules, 3-51 

canned job control streams, 3-87 
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capabilities, 2-2 

card libraries, 2-7 

comparing files, 3-28 

comparing source modules, 3-24 

compressing a file, 3-57 

control statements (See SAT librarian 
control statements) 

copying modules and files, 3-16 

correcting modules, 3-33 

creating and running a job interactively, 
3-114 

current file position pointer, 2-22 

date and time of module creation, 2-16 

deleting modules and files, 3-20 

description, 1-2, (figure) 1-3, 2-1 

disk libraries, 2-3 

diskette libraries, 2-7 

error handling, 2-14 

file allocation and management, 2-8 

general module operations, 2-9 

input/output capabilities, (figure) 2-2 

inserting linkage editor control 
statements in object modules, 3-69 

job control, 2-13 

listing and punching modules, 3-61 

load modules, 2-10 

macro and jproc source modules, 2-9 

map, 2-15 

module and group header records, 2-11 

module groups, 2-11, 3-64 

module types, 2-8 

naming conventions, 2-11 

object modules, 2-10 

page advancement for librarian map, 3-10 

printing a directory of a release volume, 
3-87 

printing a disk display of a disk file 
directory, 3-90 

printing a file table of contents, 3-58 

printing listings of modules in system 
libraries of release volume, 3-91 

printing module fields before correction, 
2-24 

processing card libraries, 2-22 

processing disk files, 2-18 

processing diskette files, 2-22 

processing tape files, 2-18 

program source modules, 2-9 

programming examples, 3-93 
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renaming modules, groups, and records, 
3-54 
resetting pointer in file, 3-7 
sequencing and resequencing source 
modules, 3-22 
skipping records, 3-42 
structure, 2-3 
tape libraries, 2-7 
using, 2-13 
SAT librarian control statements 
BLK, 3-51 
BOG, 3-65 
COM, 3-24 
COP, 3-8, 3-16, 3-60, 3-62 
COR, 3-33 
DEL, 3-20 
description, 3-1, 3-2 
ELE, 3-11 
EOD, 3-11, 3-33, 3-69 
EOG, 3-65 
ESC, 3-74 
FIL, 3-4 
format conventions, 3-1 
LST, 3-58 
PAC, 3-57 
PAGE, 3-10 
REN, 3-54 
REPRO, 3-69 
RES, 3-7 
saving on disk or diskette, 3-73 
SEQ, 3-13, 3-22, 3-37 
SKI, 3-42 
summary, (table) 3-3 
SAT library structure 
disk directory, C-4 
library records, C-2 
library blocks, C-1 
Sectors 
assigning alternates, 9-18, 10-1 
disk prep, 9-2 
sample condition table, (figure) 9-15 
Segmented program structures, overlay 
control routine, 4-30 
SEQ librarian control statement, SAT, 3-13, 
3-22, 3-37 
Sequence control field, correcting, 3-37 
SERNR keyword 
ATT routine, 10-4 
disk, 9-4, 9-10 
diskette, 9-22, 9-23 
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SETREL routine, 9-41, A-3 
Share facility, 4-37 
SHARE keyword parameter, 6-13 
Shared code processing 
description, 4-36 
effect on main storage requirements, 
(figure) 4-37 
EXTRN resolution, (figure) 4-38 
link-editing reentrant code, 4-39 
linkage in shared-code environment, 4-38 
share facility, 4-37 
shared records, 4-40 
Shared code record format, load code, (table) 
B-15 
Shared constants, 4-39 
Shared records, 4-40 
Single-phase load module, 1-4, 4-13 
SKI librarian control statement, SAT, 3-42 
SL$$SU system utility symbiont, 16-1 
SMCLIST routine, 13-1 
SMCLOG file, 13-1 
Software maintenance corrections, list 
(SMCLIST), 13-1 
Source modules 
code sets, B-4 
comparing, 3-24 
correcting, 3-36 
linkage editor, 6-7 
SAT librarian, 2-9 
sequencing and resequencing, 3-22 
(See also Modules) 
Source program files, transferring (See File 
transfer utility) 
Spiraling records, diskette, 9-25 
SPIRL keyword, 9-22, 9-25 
Standard volume labels, creating, 9-19 
Standard (non-V-CON) references, 4-31 
Statement conventions, 1-10 
Statements (See Control statements) 
STEP CMD file, D-14 
Storage, common sections, 4-26 
SU$CPY diskette copy routine, 14-1 
SU$CSL disk copy routine 
description, 15-15 
executing in batch environment, 15-18 
executing in interactive environment, 
15-15 
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SU$C16 disk copy routine 
description, 15-7 
executing, 15-2 
executing in batch environment, 15-11 
executing in interactive environment, 15-7 
interfacing with job control, 15-12 
programming examples, 15-13 
SU$C19 disk copy routine 
description, 15-1 
executing in batch environment, 15-4 
executing in interactive environment, 15-1 
interfacing with job control, 15-6 
organization, 15-4 
programming examples, 15-6 
Symbols 
definition dictionary, 7-3 
user program, 4-42 
SYSRES volume, SETREL routine, 9-41, A-3 
System access technique (SAT) 
interface, linkage editor, 4-2 
librarian (See SAT librarian) 
System files, disk, 2-3 
System librarians 
description, 1-2, 2-1 
MIRAM libraries (See MIRAM librarian) 
SAT libraries (See SAT librarian) 
System utilities 
assign alternate track (ATT) 10-1 
buffer analysis routine, 17-1 
canned job control streams, A-1 
change volume serial number 
(CHGVSN/CGV), 9-36 
copy routines, 15-1 
copy system/release file (COPYREL), 9-44 
disk, 1-5 
disk dump/restore (See DMPRST routine) 
diskette, 1-5 
diskette copy routine (SU$CPY), 14-1 
8416/8418 disk copy (SU$C16), 15-7 
8419 disk copy (SU$C19), 15-1 
8430/8433 disk copy (SU$CSL), 15-15 
file transfer utility (PCTRAN), D-1 
hardware, 1-6 
initialize disk routine (See DSKPRP 
routine) 
list software maintenance corrections 
(SMCLIST), 13-1 
prep and allocate RELEASE/SYSRES 
files (SETREL), 9-41 
system utility symbiont (SL$$SU), 16-1 
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tape, 1-6 

tape prep (TPREP), 11-1 
System utility copy routines, functions, 1-6 
System utility symbiont (SL$$SU), 1-6, 16-1 
System/release files, copying, 9-44 


T 


Table of contents, file, printing, 3-58 
Tape files 
adding modules from cards, 3-11 
librarian restrictions, 2-18 
multifile, 2-20, 2-30 
processing, SAT librarian, 2-18 
Tape functions, system utility symbiont, 16-1 
Tape libraries, 2-7 
Tape utilities, 1-6 
Tapes 
copy operation, 12-3 
copy operation in volume mode, 12-34 
dump/restore (See DMPRST routine) 
dumping disks to tape, 12-26, 12-40 
header and trailer labels, 2-19 
multifile, 2-20 
optional block length selection, 2-19 
prepping, 2-19, 11-1 
restarting dump/restore, 12-61 
restoring from tape in file mode, 12-50 
restoring from tape in volume mode, 12-31 
Temporary storage, linkage editor, 4-3 
Terminals, using file transfer utility in batch 
mode, D-14 
Text/RLD record format 
block load code, (table) B-21 
load code (table) B-16 
object code, (table) B-9 
TPREP routine 
coding instructions, 11-1 
preparing tape for execution, 11-1 
Track analysis, disk, 9-2 
Track areas, testing alternate, 9-5 
Track condition table, 9-10, (figure) 9-15, 
9-29 
Tracks 
assign alternate (ATT routine), 10-1 
assigning alternates, 9-18 
defective, recording, 9-7 
reducing latency time, 9-25 
testing alternate, 10-3 
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Trailer labels, tape, 2-19 
Transfer record format 
block load code, (table) B-22 
load code, (table) B-17 
object code, (table) B-12 
Transfer records, allocation map, 6-13 
TRCON keyword, 9-4, 9-10 
TRKCT keyword, 9-4, 9-10 
Type identifications, definitions dictionary, 
7-3, 7-4 


U 


UNXF parameter 
SU$CSL routine, 15-9 
SU$C16 routine, 15-12 
SU$C19 routine, 15-6 
UNXFC keyword 
disk, 9-4, 9-18 
diskette, 9-22, 9-26 
UPSI byte 
bit usage, 1-7 
link-edit map, 7-9 
program error checking, 1-6 
User disk files, 2-3 
User program switch indicator (UPSI), 
setting, 4-45 
User program symbols, 4-42 
Utilities (See System utilities) 


V 


V keyword parameter, 6-10 
V-CON processing option, 4-29 
V-CON references, 4-34, (figure) 4-35, 6-10 
VEFY parameter 
SU$CSL routine, 15-19 
SU$C16 routine, 15-11 
SU$C19 routine, 15-4 
VERFY keyword, 9-4, 9-17 
Verfication printer output, disk copy routine 
(figure) 15-5 
Verify-only operation, 15-5, 15-11, 15-19 
Version numbers, SAT library modules, 2-24 
Volume mode, DMPRST routine 
description, 12-33 
disk copy operation, 12-25 
disk dump operation, 12-26 
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diskette copy, 12-35 
dumping to diskette, 12-28 
dumping to MIRAM disk file, 12-29 
dumping to tape, 12-26 
PARAM statements, (table) 12-24 
restore operation, 12-31 
restoring from diskette, 12-32 
restoring from tape, 12-31 
tape copy operation, 12-34 
Volume serial number 
changing, 9-7, 9-23, 9-36 
disk dump operation, 12-8 
disk restore operation, 12-14 
specifying, 9-10, 9-23, 10-4 
Volume table of contents, (VTOC) 
building new, 9-27 
specifying address, 9-16, 9-26 
Volumes 
creating standard labels, 9-19 
disk dump, 12-8 
disk libraries, 2-3 
disk list, 12-21 
disk restore, 12-14 
release, printing a directory, 3-87 
VOLI label 
disk, 9-19, (figure) 9-20 
diskette, 9-27 
VOLI statement, 9-19 
VTOCB keyword 
disk, 9-4, 9-16 
diskette, 9-22, 9-26 
VTOCE keyword 
disk, 9-4, 9-16 
diskette, 9-22, 9-26 
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Workstations, 1-9 


Index-15 























poner - 


UNISYS 


USER COMMENTS 


We will use your comments to improve subsequent editions. 


NOTE: Please do not use this form as an order blank. 





(Document Title) 








(Document No.) (Revision No.) (Update Level) 


Comments: 


From: 





(Name of User) 








(Business Address) 


Fold on dotted lines, and mail. (No postage is necessary if mailed in the U.S.A.) 
Thank you for your cooperation 














BUSINESS REPLY MAIL 


FIRSTCLASS PERMITNO. 24 BLUE BELL, PA. 


POSTAGE WILL BE PAID BY ADDRESSEE 


Unisys Corporation 

E/MSG Product Information Development 
PO Box 500 — E5-114 

Blue Bell, PA 19422-9990 


4 


| | | NO POSTAGE 
NECESSARY 


IF MAILED IN THE 
UNITED STATES 


mn 


CUT 
4 
| 

















UNISYS 


USER COMMENTS 


We will use your comments to improve subsequent editions. 


NOTE: Please do not use this form as an order biank. 


(Document Title) 


(Document No.) (Revision No.) (Update Level) 
Comments: 
From: 


(Name of User) 


(Business Address) 


Fold on dotted lines, and mail. (No postage is necessary if mailed in the U.S.A.) 
Thank you for your cooperation 





| | | NO POSTAGE 
NECESSARY 


IF MAILED IN THE 
UNITED STATES 


BUSINESS REPLY MAIL 


FIRSTCLASS PERMITNO. 21 BLUE BELL, 


POSTAGE WILL BE PAID BY ADDRESSEE 


Unisys Corporation 

E/MSG Product Information Development 
PO Box 500 — E5-114 

Blue Bell, PA 19422-9990 


mn 









































